When do we need a contract? Organization A (or party A) wants to undertake a project and it is clear that within A there are not all necessary resources available. Then, A needs support or contributions from one or more other organizations B, C, etc. (parties B, C, etc.), to be able to carry out that project. Usually, these different parties are different legal entities, in most cases, different companies. In such situations, we need contracts between the different involved parties in order to determine and define the rights and obligations of each party.
With the following list we give short explanations of contract stuctures we often encounter:
A bi-lateral contract is the simplest project contract structure. There is one party A asking for support by another party B.
The scope of support party B has to deliver can be just about everything, from a part of a machine to a small sub-project or even the whole project, depending on the sets of skills and capabilities of parties A and B. All terms and conditions of a bi-lateral contract are under control of the two parties.
A string contract represents a string of bi-lateral contracts between three or more parties.
A contracts B, B sub-contracts C, maybe C sub-sub-contracts … In a string contract structure, the terms and conditions between two parties of the string (e.g. between B and C) are not necessarily under the control of any of the other string parties (e.g. A).
If party A wants to be in full control of all contracts it chooses a parallel contract structure.
A necessary precondition for successful contract management is: Party A needs to have all resources and skill sets of the required project management and coordination, including contract management.
For large and complex projects it might be appropriate to setup a tri-lateral project contract structure in which party A "delegates" certain tasks and / or decisions to a third party C, while party B remains the main supplier of the project results. Party C takes over partial responsibilities, e.g. in project coordination, verification of design and engineering results, or design approvals, etc.
Most of these triangular contracts are based on templates provided by the International Federation of Consulting Engineers, FIDIC (which actually stands for the French name of that organization, Fédération Internationale Des Ingénieurs-Conseils). In FIDIC based contracts, we call party A the Employer, party B the Contractor, and party C the Consulting Engineer.
There are different types of templates, including
You find a wealth of information about FIDIC on their site www.fidic.org, especially in their bookstore.
The biggest advantages of the triangular contract structure are their relevance for larger projects and the possibility of delegating certain project management and other responsibilities to a third party. However, a disadvantage is the behavior of some engineers or consultants who are scared, not able or not willing to make clear decisions - e.g. in case of design approvals - and thus, delay the work progress in their projects.
For very complex projects which need the contribution of different large companies these companies can setup a consortium. In this project contract structure, there is one contract that binds the consortium partners, e.g. companies B, C, D and E, together into the consortium, and another contract between the project owner, party A, and the consortium.
If there is one consortium partner, company B, who fully represents the whole consortium, we call it a closed consortium. In such a case companies C, D and E cannot directly deal with the project owner, party A, except through the consortium leader, company B.
In some very large and complex projects, all the consortium partner companies want to reserve the right for dealing with the project owner, party A, directly to a certain extent: e.g. design approvals, site access rights, invoicing, etc. Usually, this weakens the position of the consortium leader.
The project contract structure should always reflect the working relationships of all involved parties, as closely as possible. It should also reflect the chain of value creation of the project, as detailed as necessary. In order to make contract management, change management and claim management as well as project claim analysis easier, the contract structure should be as simple as possible.
In case you would like to use practical and useful packages of tools, templates and checklists, here you can get them. They save you a lot of time, are easy to use and easy to change:
All four PM Phases in one Set