The Contractual Containment of Risk

Placeholder image
Placeholder image
Placeholder image
Placeholder image
Placeholder image
Placeholder image
Placeholder image
Placeholder image
Placeholder image
Placeholder image
Placeholder image
Placeholder image
Placeholder image
Placeholder image
Placeholder image
Placeholder image
Placeholder image
Placeholder image
Placeholder image

Reducing uncertainties and risks to all parties involved when compiling EPCM contracts
Leonard van der Dussen

Risk is one of those short words which is known to everybody but is hard to pin down to what it really means; and what it entails. Add to that the EPCM term: also well known, often spoken in projects, but rather varied in its application. These two words in one sentence spell uncertainty.


This paper discuss risk in the EPCM project environment with the contractual framework as the tool to address risk.


This paper is specific to EPCM contracting and of a practical nature and thus is not fully developed in analysing and studying risk as such. It defines risk to some extent, but generally use the concept as the popular description of events that could lead to financial loss in the execution of an EPCM contract, and is thus primarily a commercial view of risk.

While practical concepts are discussed on how to apply a contractual framework to address risk, it is beyond the scope of this paper to review different sets of general conditions of contract conclusively.

The discussion that follows, is not a handbook or step-by-step guide, but outlines and motivates principles and attempts to focus attention on crucial elements that defines a contract with good risk management qualities.


Risk alludes to a chance or possibility of danger, loss, injury or other adverse consequences (refer Concise Oxford Dictionary). Translated into the commercial side of engineering projects, it means the possibility of money gained or lost. It is always related to technical risk and risk to life and limb as which could lead to unwanted costs.

The employer is the party desirable of the works, and the contractor the party executing the works.

A contract is the description of the arrangement between the employer and the contractor.

With “EPCM” we mean the contractual arrangement in which one party desires some engineering works to be executed, and contracts another party to provide the expertise to do so. The executing party provides the expertise but is generally spending somebody else’s money in the process and is often too small compared to the party that desires the works and compared to the project itself to be truly capable of standing up to the project magnitude to guarantee success. This view is not always true, but even if the EPCM contractor is large enough, the profits are easily absorbed if anything goes wrong and the ECPM contractor would naturally be reluctant to take on the full risk.

The instinctive motivations of the the employer and the EPCM contractor are opposing: the employer wish that the contractor would do everything possible to deliver fully come what may, whereas the contractor wish to incur only the most necessary costs and thus would lean towards doing only what is necessary and would instintively lean towards saving internal costs over possible savings on external costs, which are passed on to the employer and is thus in the final instance a risk to the employer, albeit executed by the contractor.

Professionalism, pride and a good reputation in the market to continue in business are the counteracts to the EPCM contractor’s instinctive behaviour towards internal optimisation, thus the situation has balancing factors and the existence of an EPCM part of industry, is evidence of the justification that such model exists to fill the gap between fully defined projects with employers that are willing to pay for the others to take the risk in a turnkey contract, and construction only contracts in which the employer is willing to undertake, manage and risk the engineering and design of the works, and thus accepting the process risk fully.

The very reason for the EPCM contracting model, is that the project is not fully defined at the onset, e g the detailed engineering and design is yet to be done, and that the employer has to relinquish control of the execution, while paying the bills. The EPCM contracting model exists to address an uncertain situation, and therefore loaded with risk.


The concept of project immediately flags difficulty to predict, compared to manufacturing which is more repetitive and where knowledge of consumption, rates and the like allows ongoing refinement. Projects does not start of at zero experience base, but always has a unique element, which bring uncertainty, also known as risk.

The knowledge and experience base of projects is huge, and there is little excuse for the contractual side not to provide amply for risk management. Professionals must acknowledge that the contract is drafted in the theoretical side which is easier to control than the actual digging, welding, hoisting and the like which involves many people, parts and small and large resources that can go wrong.

The contract can be described as a risk allocation document, besides allocating obligations. In an EPCM contract, the basic obligations are very simple: the contractor must do the work and the employer must pay.

A valid contract must be clear on the following minimum information:

  • What (is to be done)
  • Quantum (how much quantitively and monetary)
  • Who (the parties are)

The containment of risk starts with clarifying these essentials. The emphasize must be on clarity, which has two main components: completeness and communication.

Completeness means that enough must be stated in width (everything, scope) and depth (specification, detailed requirements) id est the type and quality level of everything required. It must however also be understandable to both parties, in other words, it must communicate well.

The habit of chucking heaps of technical specifications in its comprehensive format directly into the contract document, with lots of “just to cover all bases” documents included, is an example of splendid completeness badly communicated because it becomes unusable and the essential information is rendered inaccessible due to information overload and the contract user losing interest.

Over-detailed bills of quantities is another example of completeness killing the communication, as is the project schedule that is so detailed that the progress measurement is never up to date. A contract calling for too onerous planning requirements could add to the time risk, rather than to lessen the risk.

The first step in applying the contract as a tool to deal with risk, is to consider the balance between completeness and good communication: stating clearly and including all necessary information, but formatting it such that it is always accessible, understandable; simply usable.


Before progressing to more detailed consideration of the contract, it must be determined what the objectives with the risk handling are: whether to prevent it, whether to create paths to avoid it or whether to accepting it, but try to soften the impact id est mitigation.

It depends on the nature of the risk, it is obviously beneficial to prevent it if possible, to avoid it (navigate around it) if it can not be prevented, and as a last resort, if it is inevitable to run into it, to mitigate the chance of it occurring or being encountered and in final instance limit the damage.

When drafting the contract from a risk perspective, this three-tiered progressive approach must be followed.

It is tempting to simplify it to absolute thinking: if it can be prevented, then do so. Unfortunately the cost of implementing a risk handling level must also be considered. It stands to reason that there is more profit potential in being willing to take risks than in the predictable works execution itself, thus in the project world risk is not entirely negative and in a way it could be reasoned that too much risk prevention would disengage the industry, since the overwhelming majority of projects and contractors performing it, do so for good returns.

The consideration should be quantified to adjudicate between the possibility of a risk occurring, the severity of the possible impact and cost caused by stipulations or requirements added into the contract to achieve prevention, or avoidance. If it appears that the cost of prevention is high, the probability and the potential cost of the impact must be considered for a businesslike selection.

It is easy to state very onerous accommodation and meals requirements in a contract for a remote site project with the purpose of avoiding serious strikes, if not preventing strikes, but it increases the cost of accommodation and meals to a point where the project profitability is affected.

The risk allocation for weather related delays is often moved onto the contractor with the purpose of shielding the employer from the effects of weather delays, but by placing the risk too much on the contractor, the employer incurs cost that should be assessed before attempting prevention (from the employers’ perspective) while mitigation may be a more balanced approach.


The first step in applying the contract as a risk tool is to select an appropriate set of general conditions and a good document framework which communicates well by using suitable groupings and starts with a concise but complete table of contents.

Using an inappropriate contractual set and framework could create a risk in itself: the selection must consider:

  • whether the general conditions set:
    • is known to the parties and fits the industry
    • has a reference history (knowledge base)
    • is suited for the nature of the works
  • whether the framework used comes from a project known to the user, and that has a documented knowledge base
    • and that it is similar enough to the project to which it is now applied e g if the reference project was mainly mechanical (e g tailings conveyors) and the current project is for a hazardous chemicals plant

The last point is about the level and scope of detail specification and of safety and health requirements that is required: a tailings conveyor type project on both counts require far less detail, since the engineering and design is of general nature and expected to come solely from the EPCM contractor and can be selected without many legislative and conscience issues of protecting people; it is of a nature of a few pieces of larger equipment, compared to the chemical plant with hazardous substances, which consists of small pieces of specialised equipment and require intensive adherence to legislative issues and the conscience of the parties to prevent harm to the personnel, and of which the employer often has significant specialist input of his own to add to the project and working much closer with the EPCM contractor. It is thus expected that the detailed specifications in the contract document would be more in number, volume and level of detail.

If the contract document reference framework has for example combined the technical specifications in a section with site conditions, health and safety and security arrangements, it is because of the limited nature of technical specification required. The chemical plant contract document may benefit from placing technical specifications separately in a separate volume, or detailed reference list of specifications issued on a CD. It may sound obvious, but it has been witnessed that the use of an inappropriate sample framework has led to under-specification for a next project since it was simply not practical to place the specifications in the slot where it had been, but the compiler followed a corporate framework and got lost in the process with the completeness requirement, and thus the specifications were not truly clear and the requirements not adequately spelled out. The employer’s risk of contract cost increases and attention being diverted to claims rockets.

An example of selecting suitable general conditions of contract: a fast-track building project with large subcontract needs, may benefit from selecting the JBCC-contract, which fits the building industry and is suited to the nature of the works, but it is obvious that JBCC has no EPCM characteristics and is inappropriate for engineering.

It is less obvious to select between different option inside the FIDIC set or the NEC set, and to select between these two sets. There is in fact not a clear and universal definition of “EPCM” and thus the base document may differ, and the engineering industry should be excused for often writing EPCM contracts once-off, albeit at least borrowing from a previous project.

A key factor in the EPCM content is to check that the basis conditions are strong in the definitions and procedures of technical (engineering) completion and in the testing, handover and take-over descriptions. The outcome of an engineering project is a working plant to a certain production rate and quality, which is a live production test often requiring long and costly runs which obscures ownership and the line between project and production. This end point handling and definition is crucial to the employer’s risk towards not achieving the overall project objective, but is also the largest exposure that the contractor has, if he has to remain involved in project mode past the intended completion date, probably without further payment and consuming the profits accumulated in the project execution.

In practical words: the EPCM contract risk can be significantly reduced by good attendance to commissioning: definitions, obligations, cost methods, rates and prices, durations, procedures, documentation expected.

The conditions of contract relating to completion definition is the theoretical commercial-legal part, but require support from engineering by means of a clear requirement statement in technical terms (the “what”), including from where (e g greenfields does not require much technical battery limit detail compared to brownfields).

Once it is established that the contract being compiled is clear on:

  • what is there now (start)
  • what is required (end)
  • how it will be measured and managed to a contractual definitive conclusion

the inner workings during the course of execution, the quantums and the ancillary non-technical requirements (e g burial of the dead when working cross-border) can be attempted.

The outline must be unambiguous to enable the formulation in-between to be meaningful.

The content can be grouped as follows:

  • Form of agreement
  • Schedule of parameters (e g contract Data in NEC terms)
  • General conditions of contract
  • Special conditions of contract
  • Scope of requirements
  • Technical data and information
  • Non-technical data and information (e g health and safety procedures)
  • Price schedules (rates and prices)
  • Financial schedules (e g progress payment schedule)

The principles of suitability, completeness, accuracy and clarity must be applied to each of these sections, which are separate detailed topics each on its own.

The order of the above list is deliberate: the parties, conditions and what is to be done are inputs to the financial calculations, thus pricing and financials are logically after the inputs. Likewise the basic contractual data sets the operational scene for the contract, and precedes the more detailed technical information.


contractors often become involved for the very reason of specialist skills and capability of a world of engineering, but to execute the works under a contract require that legal, commercial and financial language is also understood. The accountant which is a good mother at home may have an egg-beater concept of a “mixer” when the engineer may be referring to a 30kW large-scale piece of equipment with structural, switchgear and control implications; and if the engineer phrases it as an “agitator” the uninitiated legal person may think of strikes, marches and labour negotiations.

It is important that people working in the EPCM environment must understand that engineering is at the heart of it and be trained and acquainted to the technology and paradigms of engineering. Contractual clarity and understanding starts with this clarity that engineering is in the centre here (a plant is about to be constructed) and the other disciplines are serving this objective.

Within their own specialised sections e g legal input into insurance exposure, meanings in the content of performance guarantees or life and limb issues, the engineer should likewise respect the inputs, but the overall engineering nature and that risks are best managed for the purpose if the plant-to-be is understood must continuously remain in view of all contractual inputs.

The reason for wanting clarity is to enable each party to understand exactly what is required, who is obligated to what, who carries which risk and to what extent.

Clarity – meaning that each party clearly understanding what is involved – limits risk and limits risk perception (the feeling of certainty or uncertainty) and provided that risk is allocated fairly to the party that is best placed to manage and decide on the particular risk – will lead to lower costs. Unreasonable risk allocation will have the opposite effect of causing cost inflation for uncertainty, whether real or perceived.

An EPCM contract should be formulated per section by the domain knowledge experts, and integrated by an experienced person who is not primarily selected based on domain knowledge, but based on experience of the whole and the personal capability to understand across disciplines. Since engineering is the core of EPCM contracts, it is expected that the contract document integrator would usually come from engineering primary domain knowledge.

The third-party test is a way of adjudicating clarity, whether the contract communicates well: how would a non-involved passerby understand a statement? Would he and the next passerby understand it the same?

Unfortunately this common law test approach is not so easy to apply to the specialist nature of EPCM works and even the complex contractual and financial methods that has to be employed to make it work. The test can still apply if you swop the “passerby” with “a third-party engineer/cost accountant/legal advisor”.

The test is usually applied using imaginative third-parties, but if the risk management advantages that can be achieved by clarity and good communication are considered, it may be money and time well spent for industry to give more attention to regular peer review. It is cheaper to do peer review upfront than to seek advice in the dispute period later on. On the other hand not all contracts end up in dispute and therefore it may be argued that it is not profitable in a group or series of projects overall to incur costs on upfront peer review.

It can be achieved to some extent by internal peer reviews (within a company), if the processes in the company encourage professional and open communication, and/or the company is large enough and willing to allows different team to comment on each others’ work. Current developments in collaborative work methods is making this not only increasingly possible, but likely that this mindset will emerge as the normal way of working in future.

General writing skills are important for clarity and understanding. This is not covered in detail here, but two particular concepts in the contractual context are highlighted:

  • ability to be clear and concise
  • using the language of the domain (engineering, project), but without losing contractual and legal meaning

The balance between clarity by writing special conditions and changing specifications from a previous similar project with some of the same parties involved to provide specific clarity, and the fact that specials distracts from clarity if a particular set of information is known to the parties, can not be prescribed. The contract compiler must test each special entry to ensure that it adds to clarity, or is addressing something that has to be addressed and is not just a point to suit a personal preference. Clouding the contract with special texts must be avoided as far as possible to maintain clarity and understanding.


Contracts are written by giving contractual names to contractual role players. Contracts are in reality managed and executed by people. Both elements – the contractual role players and the real people acting the roles – must be given clearly defined tasks and be given real names.

The general conditions of contract provides the contractual role players and allocate tasks to them e g “the Engineer” of FIDIC, and the “Project Manager” of NEC. The contract data of these contract systems calls for naming the people filling these positions, but sometimes contract compilers keep it vague be naming companies instead of people e g “The Engineer is XYZ Consultant Engineers (Pty) Ltd” and thus open up the uncertainty in making the contract intentions really work in practice, since the contract now leaves it up to a party and a appointment process outside the contract to decide who is the voice answering to provide a decision that “the Engineer” has to give.

There is a distinction between contracting parties, who would be legal persons: “the Employer” is a company and “the Contractor” is a company, and acting role players, who are given a life by the contract, but has to perform acts that require a real person.

This problem is encountered in large corporations if they do not have a willingness of designating certain contractual execution rights to an individual, and want to retain the rights and obligations of the main ruling entity in the contract for themselves and not designate it to an external consultant. In that case there is a way of at least pointing to a specific office by defining (e g) “the Engineer” as “the Group Engineering Manager” thus allowing the corporation to change personnel and allocate responsibilities, but at least give the contractor a more definitive address to deal with than the worst case of equating “the Engineer” simply to the company. The undesirable position that this also leads to positions where the contractual leader and the employer is the same, is another debate. If it is correctly defined, at least the contractor knows upfront that the contractual leader and the employer is the same and can consider the risk exposure that is caused by this over-powerful position.

The contract must be clear – or made clear by special conditions – on the requirements for delegation of authorities. It is recommended that such possibilities must be stated in direct terms and must require specified written notifications to the other party. The lack of definition on who the role players are in reality, and what there limits and obligations are (e g whether somebody is compelled to make a decision) is a major cause of project uncertainty. A fallback clause to indicate what a party should do if such designations are unclear, is desirable to close this loop: often the contract provides suitably for these allocations and designations, but it falls flat due to poor execution thereof. Then a fallback clause to enable enforcement is required.

It is unusual for a contract to state who may not do certain things. The distinction between role players in the execution of a contract, and stakeholders is to be dealt with outside the contract. The method to ensure that stakeholders act appropriately by not entering the contract arena, but to work with their contractual role players to influence the works, is to state the contractual role play very strongly such that it comes across that only this role may do certain things, and that THIS role MUST do certain things. The typical example is when the employer does not respect the difference between being in general terms “the client” and being the party called “the employer” in the contract: a client may have a valid reason for wanting to change certain things in the project, or to give certain new safety instructions, but must be held to the contract that require that such variations or corporate decrees are implemented via the contract and not by external interference. The latter is a cause of uncertainty, but the nature of EPCM contracts of which one of the reasons for contracting in the EPCM manner is for the employer to retain flexibility in the layout and design and being able to instruction variations, sometimes leads clients to believe that such variations can be decreed from outside the contract, and due to inexperience and lack of the contractual knowledge, often giving such instructions incorrectly and inappropriately with disruptive effect.

Optimised project results require not only a clear contract on roles, responsibilities and defining those acting the roles, but also a step further for the actors to engage with their stakeholders and keep them outside the contract execution.

Uncertainty about roles and persons acting those roles is a considerable factor when a contractor assesses his contractual risk.


Once the contract have been compiled with due and good understanding of how to make it into a sharp tool with clarity, being complete and usable and understandable, it is in danger of remaining an unused tool. Modern contracting is sophisticated and contracting benefits from good legal correctness, and is thus not easy to read and understand in practice by everybody on the project.

The sheer volume combined with different persons involved having particular interests only e g commercial, or technical, or only a a particular discipline of technical, or safety and health, adds to the challenge of making the contract a read and used document during the project execution.

The solution is to first of all appoint a contract champion, that is the communicator and creates enthusiasm that the contract is an asset to the project. This is by default thought to be the project manager’s responsibility, but the contract training and promotion should be a dedicated task, particularly at the onset of the project, and it is not a given that the project manager is a contractual enthusiast nor is he by default the most knowledgeable on the contract mechanisms.

The active promotion of the contract and training people formally and informally in its practical use, should receive more attention, such as have been witnessed on some projects where an enthusiastic procurement manager would take this responsibility e g by spending time on paging through the contract document with tenderers at the site inspection meeting, giving an overview and drawing attention to crucial matters or matters known to be often neglected or misunderstood, and to arrange dedicated kick-off sessions with the project participants in the early phases.

From thereon, the project leader must see to it that the contract mechanisms are adhered to. A mid-project audit of practical adherence to obligations, role players and whether decisions and instructions are truly rounded off and executed, is not a popular idea, but could significantly contribute to risk reduction. E g clear instructions issued, conveyed and managed in the contractually correct manner, would add to certainty rather than to cause anxiety. If variations, instructions and clarifications are however badly conveyed and managed, costs for extras increase due to risk perceptions and the risk of misunderstandings increase.


The EPCM model is uncertain by its very nature. The contract is pivotal in arranging it clearly and practical. If the role of the contract document to be a risk allocation instrument is understood, and the contract compiler take due cognisance of the necessity for combining general (such as basic writing skills) and domain specific (such as engineering demarcation and assignment of responsibilities) skills, the contract document can significantly reduce the EPCM contract risk and create space for amicable and productive project execution.

About Us

VDDB provides project structuring, execution and control services that makes projects predictable and controllable. Some clients prefer the full project office function, including procedures, procurement, contract administration, policies and general project execution and co-ordination, and use selected services.


The concept of analytical quantity surveying is one of numerous enhanced services where traditional skills are merged with information management tooling to provide strongly enhanced project services in a fast world which is keen for optimisation.

Get in Touch

  • Phone:
    +27 12 534 3160
  • Mail:
  • Address:
    Fountain Square, Floor 2, Office 204,
    78 Kalkoen Street, Monument Park X2, Pretoria, South Africa, 0157