Credit: Svjatoslav Andreichyn/Shutterstock

Design-build infrastructure projects are increasingly the subject of large, complex disputes. These disputes often centre on the evolving nature of the designs as projects progress from tender through to for-construction drawings. The three main stakeholders – owner, contractor, and design subcontractor (designer) – frequently disagree on the allocation of responsibility for incorporating changes and the associated cost overruns. This article discusses the types of disputes that arise between contractor and designer from the technical expert witness perspective and suggests ways in which disputes can be avoided. The article is divided into two fundamental types of disputes: (1) tender-phase disputes, where the contractor claims that errors or omissions in the designer’s tender phase design have led to an unachievably low bid price; and (2) detailed design-phase disputes, where the designer and contractor disagree on whether design changes after tender are normal and expected design development or should have been anticipated at time of tender. This article does not address disputes over delay and quantum, which we recognise are an important part of any design/build dispute and require careful coordination with technical experts.

Tender-phase disputes

Tender-phase designs prepared under design-build contracts are ripe for disputes because low pre-award budgets and paucity of information require the designer to make gross simplifications and assumptions, which will be tested during design development. Should those assumptions and simplifications be found either incorrect or inappropriate, the effects on the ultimate success of the project can be considerable (eg, the contractor not providing adequate provisions for materials, not anticipating complicated construction procedures required to execute the ultimate design, etc).

Scope of design during the tender phase

Because tender phase designs are high level (typically 15 to 30 per cent completion) and designers will be reluctant to perform additional scope beyond their contractual obligations, the scope of tender designs should be explicitly defined in the contract. In one recent dispute, the precise scope was unclear because several line items in the designer’s scope of services did not have a cost assigned to them while others did. Was this to imply that the item was out-of-scope or a zero-cost task within the contract scope? Either assigning costs to all line items or using a lump-sum approach would have avoided this question and the associated disputes.

Scope creep during the tender phase can originate from the contractor requesting additional refinement of the designs to relax conservative assumptions and allow a more competitive bid. In addition, the owner’s design criteria could change during tender for a variety of reasons. Given the low budgets and tight schedules that typically characterise tender phase designs, the designer should make it clear to the contractor precisely which requirements were or were not considered given the budgetary and time constraints.

Use of prototype designs

For civil infrastructure projects with repetitive major design elements (eg, bridges, metro/underground stations, and tunnels), contractors may be motivated to price the works based on a prototypical tender design of each element type. However, actual costs for each design element can vary significantly if site-specific conditions are not properly recognised and addressed. In our experience, responsibility for considering and accounting for variations to the prototype during the tender phase can fall on the designer, contractor, and in some cases, both.

These can include alternative structural forms based on local differences in geometric site constraints, differences in soil and groundwater conditions, temporary traffic management, temporary and permanent roadway modifications, and utility diversions. It is critical to establish who will account for these variations at tender. For example, the designer may be best suited to anticipate the structural implications of a varying water table, but the contractor is better suited to estimate the implications of associated traffic and utility diversions.

How differences between prototypes and site adaptations are documented is critical. For example, the designer could simply list the aspects of a design that differ (at a high level). Alternatively, we have seen where designers have been asked to provide ‘uplift factors’ related to perceived complexity of construction. These factors can be the subject of criticism in disputes if the bid price falls short of what is ultimately required, and untangling the accuracy of the factors in conjunction with the numerous additional changes that typically occur during the detailed design phase is complicated and fraught with challenges.

Pricing the differences between prototype and site adapted elements will typically be in the domain of the contractor, since designers deal in engineering quantities associated with particular design elements, and not the cost expenditures necessary to build those elements given a set of site constraints. Designers should be wary of providing factors related to pricing the works, and if they do they should make clear what has been considered and distinguish between aspects of the factors that are driven by design versus construction.

Pricing responsibility

While ultimate responsibility for pricing lies with the contractor, the associated quantities are derived from tender designs, and contractors may pursue claims against the designer for alleged design flaws that informed the pricing. Designers should be especially wary of participating in the preparation of bills of quantity (BoQs) in the tender phase, in lieu of the contractor developing BoQs based (in part) on the tender drawings. The tender design information is necessarily incomplete, and the contractor is likely to base its BoQ on experience constructing similar facilities. Notably, it is easy for a designer (or contractor) to omit an element from a BoQ in the tender phase that is outside the tender design scope (eg, secondary steel or rebar wastage). To avoid confusion and later disputes, designers should identify items included or excluded in their BoQ as precisely as possible.

Recently, the authors encountered a contract in which the designer was required to provide BoQs for ‘major cost items’, which was not explicitly defined. Structural engineers typically distinguish between primary member and secondary members based on their function, not on cost. Beams, columns, slabs, foundations, and walls are examples of primary structural elements, while hangers for façade elements and piping supports are examples of secondary elements, which in some cases are never designed by the structural engineer, even in the detailed design phase. The designer may not be aware of the items that are ‘major cost’ because they are not pricing the works. In this case, the contractor argued that elements of secondary steel should have been included in the designer’s BoQ because they were ‘major cost items’, a determination that only the contractor could make.

Appropriate level of detail

In design-bid-build projects, contractors prepare bids based on fully developed contract documents at the end of the detailed design phase. Disputes can arise in design-build projects around what is the appropriate level of detail for a tender-phase design. The level of detail should be compatible with the definition of ‘major cost items’, discussed above. For example, should electrical conduits in bridge barrier rails be included in tender-phase BoQs? The level of detail included in the tender phase design should be commensurate with what is required to reasonably price a job. A contractor can assume that conduit is required in bridge barriers, so a designer may not need to include this detail in tender-phase drawings or in BoQs to enable accurate pricing. Because the designer adds details, but the contractor prices them, they may speak different languages in terms of the level of detail required to price the works, which can lead to inconsistencies, omissions, and disputes.

Value engineering

Value engineering (VE) will typically occur during the detailed design phase to reduce construction cost. It can, however, also be implemented during the tender phase to help reduce the bid and increase the chances of being awarded the project. Importantly, this is a corporate risk decision to be made by the contractor in its preparation of a final bid. Due to its high-level nature and the short time frame in which tender-phase designs are typically developed, VE will often occur after the tender design has already been completed and the design team has demobilised, leaving limited resources available to either verify the likelihood that VE proposals can be achieved or to understand cascading consequences should they be implemented. Disputes can arise when well-intentioned VE proposals cannot ultimately be realised, which can occur for a myriad of reasons, for example, changes to the owner’s requirements, unforeseen site conditions, or subsequent detailed calculations show that the VE savings could simply not be achieved. We have seen several instances in which the contractor has pursued the financial value that was VE’ed out of the bid price in consultation with the designer but never actually realised. In such cases, one must wonder whether the bid would have been successful without the VE price reduction having been offered. Designers and contractors should realise that VE proposals based on limited information at tender cannot guarantee that a design change will result in reduced project cost.

Compliance with the owner’s requirements

Invitations to bid for large infrastructure projects will typically include detailed requirements for the design, including exemplar plans and performance specifications, which are sometimes referred to as bridging documents. To the extent an element of the design is shown on the tender drawings, it should comply with the owner’s requirements, or the deviation should be noted and requested to be approved in the bid. Otherwise, the contractor may claim that the designer failed to warn it of non-compliance of the tender design if ultimately complying with the owner’s requirements is more costly than was accounted for in the bid price.

Contractors and designers can also find themselves in disagreement as to whether the tender phase design complied with the owner’s requirements when the design element in question was not included in the tender phase design. Omitting a major element of work in the tender design could be problematic, but in some cases, the design simply had not progressed far enough during the tender phase to demonstrate compliance with all the owner’s requirements, which apply to the finished work. For example, an owner may require that concrete reinforcing comply with certain industry standards, but such compliance cannot be demonstrated on a tender phase design if the details of concrete reinforcement are only developed later during the detailed design phase. The appearance or non-appearance of details in the tender design can simply reflect the level of design development rather than signify a failure by the designer to (ultimately) comply with the owner’s requirements.

Addressing a lack of data during the tender phase

The lack of detailed design data, such as flood elevations, topographical data, and geotechnical reports, during the tender phase is often an unpleasant (but unavoidable) challenge that results in significant uncertainty. During the tender phase, the owner will typically provide some site data, but it is unusual for a designer or contractor to acquire precise field data prior to detailed design development. Imagine the chaos of ten bidders in the field measuring road widths at the same intersection, before any contracts have been awarded. Disputes can arise when updated site data is only available after the award of the contract, and, as a result, changes to the design are required. For example, a contractor may claim that the designer should have anticipated that flooding would need to be considered as part of the tender design (which would have led to a higher bid price), while the designer might argue that no information available at the time would have alerted it to that fact or enabled it to design for floods with sufficient detail to affect pricing.

Standard of care

Standards for designers (reasonableness) and contractors (fitness for use) can become muddled in the design-build context where contractor and designer work as a team. It is also important to avoid conflating the standards for tender design with for-construction design in terms of the completeness of drawings and the precision of the analysis. Clear definition of the designer’s standard of care and what is expected to be shown on the bid documents is critical to avoid future disputes.

Detailed design-phase disputes

Design development versus design scope changes

Since design-build projects are awarded based on preliminary designs that may only be developed to 15 to 30 per cent, many aspects of the project obviously have yet to be firmly established, and even some conceptual design criteria may be subject to change. Neither the contractor nor the designer can reasonably expect that the post-award detailed design effort will consist of a linear process of simply committing fully formed ideas onto a set of construction documents. The authors have seen contract language that reflects this mutual expectation, such as the requirement of the designer to host frequent review meetings and perform iterative design development incorporating interfacing party requirements to secure approval/acceptance as necessary. Understandably, disputes arise between contractors and designers over where the boundary lies between normal design iteration and a change to the designer’s scope of services.

It is also generally understood that a designer’s tolerance for ‘iteration’ will generally decrease as design development progresses, as the amount of associated abortive work will likewise increase. Furthermore, revisiting or modifying designs that have already been subjected to interim reviews by the contractor or the owner at established milestones produces sudden decreases in the designer’s willingness to accommodate a change. The authors have seen contracts which define ‘design freezes’ after contractor and/or owner reviews are complete, and the explicit requirement that the designer be compensated for instructed changes that come after design freezes.

The appetite of a designer to accommodate (uncompensated) changes in direction from the owner, contractor, third-party stakeholders, or other interfacing design disciplines is illustrated conceptually in Figure 1. The figure shows that the designer’s tolerance decreases precipitously as design milestones (freezes) are crossed. The design at each milestone provides the baseline against which future changes and subsequent effort are measured.

Engineering design is famously non-linear and recursive, requiring numerous iterations and interfaces across various disciplines to develop an acceptable solution. However, this does not entitle design-build contractors to demand infinite re-work from their consultants. While it is impossible to establish in the abstract all of the activities that should always be included or excluded from normal iterative design development on a hypothetical infrastructure project, we hope that the following examples are helpful for contractors and designers in efforts to anticipate problematic scenarios and avoid conflicts.

Alignment or base geometry changes

The geometric framework for many civil engineering projects is formed by horizontal and vertical alignments. This is the case for linear features such as roads, bridges, railways, tunnels, levees, dams, and improved channels. Similarly, the column grid and the floor elevations establish the geometric baseline for buildings. These geometric design elements must be established early in the design process, as any changes to them can cascade throughout the project both in space and across all the affected disciplines.

For example, raising the profile of a bridge can affect the abutment locations since they may be limited in height. In this scenario, the bridge must lengthen, and the impacts of the increase in length could include increasing the number of spans, relocating the interior piers, or changing the superstructure type (eg, using steel girders to accommodate spans longer than those practical with precast concrete girders). The adequacy of foundations would have to be assessed, depending on the variability in the soils or the changes in the loads. Apart from these basic structural impacts, the drawings will all be certainly affected. At the very least, referenced views will have to be updated and annotations modified. The number of drawing sheets required to depict the bridge may also change, and new matchlines would have to be established. From a plan production perspective, it could be tantamount to starting again.

While there are some design functions that can occur in parallel with establishment of base geometry (eg, the development of some typical details or the establishment of generic calculation worksheets), progress towards the next design milestone does depend on the establishment of base geometry. And there is the possibility that major changes to base geometry could also render some of the work product from parallel activities obsolete. Contractors risk setting a trap for themselves if they agree a fixed price and are willing to accommodate externally-driven alignment changes after the execution of the contract with the owner.

Consequences of design contract fragmentation

The authors have seen instances in which some design activities on large projects are contracted separately, even though there are significant interfaces between the various scopes of work. An example is separating contracts for the design of railway stations from that of the track itself. In addition to the obvious, overall challenge of coordinating technical work across separate contracts, another potential pitfall is in introducing incompatible milestone dates across the contracts. The milestone dates in each of the contracts should reflect how designs actually progress, that is, the milestones in each contract should not be out of phase with each other. A change to an interfacing design can act like a change to base geometry and cascade through space, across disciplines, and across contract scopes.

Coordination with third parties

Complex infrastructure projects interface with wide constellations of third parties. Examples include utility providers, property owners, and owners of other intersecting infrastructure. For example, contractors building a new motorway that crosses a railway line can expect complications. The contracts between the contractor and the owner and the contractor and the designer must be clear regarding who has the authority to identify the interfacing parties and coordinate and negotiate with them. It is sensible that the owner would retain this responsibility, since neither the contractor nor designer is a principal that can require the owner to coordinate with other entities. Nevertheless, the authors have seen instances in which contractors have criticised their design subcontractors for failing to perform this function. Designers would normally be expected to coordinate their designs with third-party requirements and doing so is within the realm of usual design development. However, this depends on timely communication of such requirements to them from the contractor. It is the contractor’s or owner’s responsibility to ensure that proper coordination has occurred at the appropriate milestones. If the design has progressed significantly by the time that a third party’s requirements are communicated to the designer, a change in the designer’s scope and corresponding adjustment to their schedule or compensation may be warranted. If the delayed coordination was caused by the owner, then the contractor would be reasonable in pursuing this claim with the owner. Responding to late arriving third-party requirements is not typical design development. The issues described here also apply when the design subcontracts are fragmented and interfacing designers are third parties to one another.

Owner-driven changes

Large design-build projects are complex and multi-faceted, and it is not unusual for the owner’s expectations to evolve as the project develops and as implications of the design become better understood. When owners ask for changes to the design after the execution of the contract, contractors would be expected to submit a change order to the owner to cover the difference in time, labour, equipment, and materials that is represented in the change. Similarly, to the extent that the owner-driven change affects the work of the designer, the designer would be reasonable in submitting a request to the contractor for an adjustment to its schedule or compensation. The authors have seen instances in which contractors claimed that an owner-driven change entitled them to more compensation but then rejected a designer’s claim that the associated design work was a change in the design scope. Modifying a design to comply with owner-driven changes is clearly outside anticipated design development.

Value engineering

Carefully evaluating the design to reduce costs while still meeting the owner’s requirements has the potential to yield tremendous financial value to the project, so it is enticing to conduct VE exercises during detailed design. If, as a result of a VE exercise, the contractor determines that changes should be made to the design, implementing the changes would not constitute normal (iterative) design development as long as the original design was reasonable. The authors have seen design subcontracts that require the designer to provide an economically efficient design where the criteria for what constitutes an efficient design is not included. In this scenario, the design subcontractor may be at risk of being required by the contractor to rework its otherwise correct design, without compensation, simply because it did not represent the solution with the lowest cost. A designer’s responsibility to provide an efficient design does not saddle it with the burden of providing the optimal design. Discovering and providing the optimal design, which may vary by stakeholder or perspective, is not within a designer’s normal standard of care. A design which is considered an optimal design in the view of all stakeholders is unlikely to be provided in the normal course of design development.

Claim substantiation

The authors have seen circumstances in which a designer’s claims for adjustment to their compensation have been subjected to rounds of rejection on the basis that the claims were not properly substantiated, as required by the design subcontract. What constituted proper substantiation was not defined in the contract, however, and the degree to which documentation, narrative descriptions, and work breakdowns were to be developed to support a claim was in the eye of the beholder. As one might imagine, the designer was not inclined to provide the volume and level of detail in their supporting documentation that the contractor deemed necessary. Clearly defining in the contract documents how design scope changes are to be substantiated at the outset could help avoid such disputes.

Designer descope

One of the more complex types of disputes can occur when a designer is descoped (ie, dismissed or terminated) prior to completion of the detailed design. Notwithstanding contractual provisions regarding whether the descope is legal, there can be disagreements regarding how far along the design had progressed at the time of the descope, and the appropriate compensation for the partially completed design.

Disagreements can be minimised if the contract clearly defines what work is to be completed at each milestone that triggers payment. The expected deliverables can be identified based on the milestone descriptions, which can be checked against the design in existence at the time of descope. One must also consider the extent to which change orders have been incorporated into the design, and the interaction between the change orders and the original design scope. For example, if a change order is issued that states that a tunnel should be designed instead of a bridge, and the next day the entire design is descoped, the progress towards any milestone would be nought per cent. However, the designer should be compensated for their work prior to the change order. The work that was aborted and additional work that otherwise would not have been required prior to the change order must be carefully considered. When assessing the level of development of terminated work, consideration should also be given to whether calculations or numerical models sufficiently support the design that has been documented in drawings or building information modelling (BIM), and if proper coordination has occurred between disciplines for the current status/milestone.

A final complication appears when one considers the effort required by the new designer (post-descope) as part of calculating the payment due to the original designer for their work that was completed prior to descope. The new designer must repeat certain works already undertaken by the original designer, and it can be substantial if they use different computer software or simply have different internal standards or templates for the engineering and drafting.

Level of effort for changes to design scope

In the event that a designer and a contractor agree in principle that the designer is entitled to adjustment to its compensation due to a change in its scope, there is still the delicate matter of determining the appropriate level of effort that executing the change will require. Substantiating an estimate of level of effort could involve demonstrating the status of the design at the time of the change, estimating how far the design had progressed from the previous milestone toward the next at the time of the change, determining how much of the already-completed design was altered by the change or how much additional (rather than altered) design work was added by the change, estimating the time required to carry out the change (broken out by labour category), or reporting how much time was actually expended carrying out the change.

Approaches to tackling this problem depend in part on whether the work has already been performed when the claim is being substantiated. Designers may estimate level of effort as a proposal to the contractor for changes that are still being contemplated, or they may substantiate level of effort to claim compensation for work that they have already conducted. Level of effort estimates are further complicated if there are concurrent design changes happening on the same area of work.

Regardless of the method of substantiation, as soon as the designer suspects that it will be required to perform work that is not within its scope, the designer is advised to establish internal cost codes to track any time spent executing the change and be diligent in correctly allocating time to the appropriate codes and including descriptive comments with each timesheet entry. This data can provide useful documentation of the effort that was actually required to carry out the change in the event that compensation is not agreed prior to the execution of the change. Also, the designer should archive the status of the design at the time of the change so that the baseline of what work had already been accomplished is clear.

Estimating the level of effort in anticipation of a change is no different from estimating the budget for any other project. The designer should break the work down into as many component tasks as possible and estimate how many hours from each applicable labour category will be required to carry out each of the tasks. A rule of thumb for the proper breakdown of component tasks is that each task should represent between eight and 80 hours. Smaller breakdowns are not generally useful, and tasks requiring more time than 80 hours can probably be broken down into smaller components for which the effort can be more accurately estimated.

If the work is already underway or has already been completed and the cost codes were not established and the design status was not archived, the designer will often need to build up an estimate of the work that was actually performed. This can be done in a manner similar to the estimating process described above.

For engineering designs, the number of design drawings is a useful denomination of effort. At the outset of the project, there is usually some understanding on the part of the designer of the number of drawing sheets that will be required to communicate the design. At that time there is also an agreed fee for the work. If this fee was built up from a breakdown of the hours required to complete the work, then the total number of hours is readily available, and the hours per sheet can be calculated. If the fee was not developed on the basis of a breakdown of tasks and hours, the total number of hours required to carry out the project can be estimated by dividing the fee by an appropriately blended labour rate. Then this number of hours can be divided by the anticipated number of sheets to determine the hours associated with producing each drawing sheet. In the authors’ experience, hours per sheet is a useful heuristic commonly employed by designers to estimate or validate design fees. This metric can also be used to estimate the level of effort required to carry out a design change by applying the quantity to the number of affected drawings and considering the degree to which the drawings was affected. This method of estimating the level of effort to carry out a design change is especially useful when scope changes are subject to lump sum pricing.

Summary

Design-build projects carry inherent risks since contracts are often awarded for a fixed price based on preliminary designs. Disputes can arise between contractors and their design subcontractors when projects become more costly or complicated than anticipated at the time of bid. The contractor may question the quality of the tender design and could pursue claims against the designer that hinge upon issues including the definition of the designer’s pre-award scope, the use of prototype designs, how responsibility for estimating quantities is distributed, how much detail can be expected to appear in the tender design, whether the tender design complied with the owner’s requirements, or whether the impacts of post-award site data should have been anticipated by the designer.

Once detailed design is underway, it is not surprising to see the scope of the designer’s work diverge from pre-award expectations since the original scope was based on a preliminary design and necessarily incomplete site information. The authors have seen disputes between contractors and their design subcontractors over what constitutes a change to design services, what responsibilities designers have in coordinating with third parties, and how designers should properly substantiate their claims regarding scope changes. Anticipating these pre-award and post-award pitfalls can provide an effective strategy towards preventing them. Carefully considering these in negotiations, contractual agreements, and other project communications can alleviate their impacts. When they do occur, disputes on design-build projects often have a technical basis, and experts in the appropriate technical fields can help sort out the differences between the parties.

Ezra Jampole is a managing engineer in the buildings and structures practice at Exponent in New York City, and can be contacted at ejampole@exponent.com. Samuel Amoroso is a managing engineer in the buildings and structures practice at Exponent in Houston, Texas, and can be contacted at samoroso@exponent.com. Troy Morgan is practice director and principal engineer in the buildings and structures practice at Exponent in New York City, and can be contacted at tmorgan@exponent.com. Brian McDonald is a corporate vice-president and principal engineer in the buildings and structures practice at Exponent in Menlo Park, California, and can be contacted at mcdonald@exponent.com.