Reading and understanding the contract While it may be rudimentary, the first element in successfully completing a design submittal is to read the contract. With the shift in risk to the DB team by public owners, many contract speci- fications governing design are requiring a level of detail and transparency that were not required in a traditional design-bid- build (DBB) procurement. One reason for this increase in the level of detail required is that a public owner in a DB procurement is less involved in the final design process. While the design and construction risk is shifted during the term of the contract and a warranty period, the public owner is still responsible to the public, which it serves, for the life of the project. A typical level of design prepared by a public owner for a DB contract may only be 10% to 15% for a surface transportation project. Hence, the level of detail to present and defend design decisions as well as to deliver as- built construction records for archival purposes is much higher than what an engineer new to DB may be accustomed to preparing for a DBB procurement as an owner’s representative. An example of this increased level of detail required in a design submittal might be the verification and justification of soil properties and parameters for design. This is a technical requirement in a Washington State Department of Transportation (WSDOT) DB contract. Within the design submittal, an analysis (with supporting calculations and backup references) and justification of the variability and uncertainty of the soil properties must be reported, and the selection of properties and parameters for design must be defended for contract compliance. Depending on the available information, this documentation may be a statistical analysis or the use of empirical procedures, including a full reporting of all of the equations and their reference and how the data was used to arrive at the final solution. In either case, a concise written position statement must be presented and defended, and the impact to construction must be included in the design submittal. The amount of effort needed to be contract compliant is more than an engineer who is not experienced in DB 78 • DEEP FOUNDATIONS • JAN/FEB 2018 procurement may be accustomed. Without this level of detail, a submittal will not be contract compliant and will be returned to the DB team with a set of detailed comments that must be addressed, potentially impacting the project schedule and design time if rework and resubmission is needed. It is tempting for a DB team to argue that a certain design decision is within the rights and responsibilities of the engineer of record (EOR) or that a decision is based on “engineering judgement.” A statement on a design decision or a response to a comment that is “deemed suitable by the EOR” should be not be accepted by an owner. While it can be argued that a design decision based on “engineering judgement” does not need documentation, supporting a design decision with relevant data, a logical stream of thinking, and an empirical or theoretical basis is a more valid approach, which also avoids an impression that one is simply guessing or avoiding the additional effort. Arguing compliance solely from a position of “engineering judgment” will damage relationships with the owner, and could plant seeds of an adversarial environment going forward, which would be detrimental to all parties and to the success of the project. Reading the contract also entails a correct interpretation and understanding of all of the requirements for compliance. There can be a tendency for contractors and engineers new to DB to interpret a particular contract clause and either willingly or unwillingly decide that a particular requirement is not what the contract means based on their experience on another contract. An example might be that the contract language states that integrity testing “shall” be performed on “all” drilled shafts; however, on past projects, the DB team did not perform integrity testing on shafts constructed in the dry. As a number of the drilled shafts on the current project will be constructed in the dry, the DB team could take the position that they will not test “all” the drilled shafts. In this case, the submittal is returned as either noncompliant or with comments, which have to be formally addressed, requiring extra time and cost, which may interrupt the work in the field. Clearly, either result has a negative impact to the project. Read the contract carefully, and ensure the question is answered with the appro- priate and correct response. Prior contract experience may be useful, but the current contract requirements are what must guide construction and design decisions. The arguments, “That is what I have always done” or “That is what I did on the last con- tract,” are not relevant. Contractual compliance and con- structability are the goals of a design submittal. Design submittals do not have to be long, but should be clear, concise, complete, logically presented and in con- tractual compliance. The technical sub- mittal must be a defense of your design, and should include: • A clear statement of the purpose of the design element being addressed • Design decisions • Supporting information defending the design decisions including any assumptions that were made, alter- natives considered along with easy to follow calculations, relevant codes and specifications, references relied upon, and the logic that was used to arrive at the decision For example, in selecting a design value for a material property, a range of options could be available. Explain how this selection complies with the contractual requirements, and how it relates to con- struction and to the overall safety and reliability of the design element. Contracts are not perfect To meet their project objectives, public agencies work hard to provide a fair and responsible contract. However, contracts are not perfect. While it is best to catch discrepancies prior to a contract award, sometimes things do slip through the cracks, and a problem with specific contract language is not identified until the project is well into construction. Willful ignorance is not the recommended strategy should discrepancies or issues occur. Similar to the notification clause for a differing site condition, early and honest notification is the most desirable course of
