Demystifying progressive design build: implementation issues and lessons learned through case study analysis
Article Category: Case Study
Data publikacji: 22 kwi 2020
Zakres stron: 2095 - 2108
Otrzymano: 15 gru 2019
Przyjęty: 10 lut 2020
DOI: https://doi.org/10.2478/otmcj-2020-0006
Słowa kluczowe
© 2020 Luming Shang et al., published by Sciendo
This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
Design–build (DB) is a project delivery system that provides a way to overcome the inherent drawbacks of the traditional project delivery methods, such as design–bid–build (DBB). In the US, DB has been used by public owners for decades. Typically, a single entity contracts with the owner to provide the design and construction for a DB project. The solicitation is usually based on one of three approaches, including low bid, one-step BV, and two-step BV (Migliaccio et al. 2009). The project owner must take two major considerations into account during the tender evaluation phase: qualifications and price. On a traditional DB project, the owner usually contracts with an independent design consultant to develop initial project preparation and conceptual design prior to request for qualifications (RFQ) issuance. The owner then issues an RFQ to declare his/her project requirements and parameters, expecting firms to respond to it through their statements of qualifications (SOQs). Once the owner team evaluates these SOQs, it develops a short list of the responding DB firms; then, it releases its request for proposals (RFP) to them. Once the shortlisted teams submit their technical and price proposals, the owner team selects the winning team through a multicriteria evaluation process. In traditional DB, the RFP typically presents the owner’s requirements as specifically as possible, and it usually is the owner organization’s last chance to clarify its expectations (Minchin et al. 2014; Lopez del Puerto et al. 2008).
The success of the traditional DB project depends greatly on the predesign and/or bridging documents. In the RFQ phase of projects with a design competition, the predesign and/or bridging documents provide prospective contractors with the information they need to assemble the right team. In the RFP phase, a comprehensive predesign helps the DB teams to avoid confusion or misunderstanding and work from the same basis of design. Additionally, a well-designed preparatory document can greatly reduce the uncertainties and potential problems of subsequent change orders (Gibson et al. 2007). Thus, to ensure a project’s success, a public owner usually has to spend adequate time and resources on the predesign to prepare a clearly defined program, scope, and budget. However, this need for extensive preparation can be a burden for the owner and often lengthens the project duration overall.
As an emerging alternative to traditional DB, progressive design–build (PDB) enables the owner to select the DB team prior to finalizing the project program and/or budget. It also has the advantage of maintaining a single point of accountability and uses qualifications as the fundamental selection criterion while limiting the consideration of price factors. Under the PDB approach, the selected DB team works with the project stakeholders to complete the predesign, balancing the scope and the budget (Migliaccio and Holm 2018). Moreover, the key to the effectiveness of PDB lies in its ongoing and complete involvement of the owner in the design phase. What owners must understand is that every decision has cost implications, and that any change to these decisions might increase costs. Knowing the costs associated with the project in a timely manner increases the owner’s perception of the contractor as an ally—no longer as a party always ready to take advantage of the circumstances to increase the profit margin. The collaborative PDB environment fosters innovation and, because of its continuous involvement, the owner team can provide timely feedback and directives during both the design and the construction phases.
To enable a comprehensive understanding of the PDB method, this paper first chronicles the emergence of PDB and then presents a descriptive case study of a building project to illustrate the characteristics of PDB in detail. Finally, it presents the project’s lessons learned to provide best practices for future PDB implementation. This article is the extended version of a conference paper (Shang and Migliaccio 2019) and is intended to complement existing literature on PDB for transportation and water-and-waste-water projects (Herbst and Edmondson 2012; Alleman and Tran 2019; Gransberg and Molenaar 2019) by providing detailed information on implementing PDB on building projects.
Several factors contribute to the emergence and/or evolution of a project delivery method, such as the competitive structure of the industry, regulatory requirements, and changes in responsibility and risk allocation. In Washington State, the implementation of PDB in public works became possible after legislative adjustments made in 2013. Before the legislation change, the owner of a DB project usually had to include a significant amount of design work (15%–35%) in the RFP to give the proposers an effective basis of design for their technical and price proposals. Similarly, the DB proposers had to expend much effort on design before knowing whether they will be awarded the contract, because during the selection phase, standing law required a proposal price based on a significantly complete design (usually 35%–60% complete). The legislative change removed the “proposal price” from the required evaluation criteria during the RFP phase and was replaced by a “price-related factor.” This change means that DB proposers no longer have to provide a design or estimate during the solicitation phase. Moreover, it allows the owner to choose the most appropriate team, primarily on the basis of their qualifications, and to complete the design with the selected team; these two changes represent the core distinctions between PDB and the traditional DB. In traditional DB, especially with the low-bid approach, some outstanding teams/designs fail due to relatively high price. The replacement of the “proposal price” rule with the “price-related factor” helps eliminate the best design/lowest price dilemma.
The legislation change also provides public owners more freedom to base their choices of the most appropriate delivery methods on their particular situations. If the owner organization has clearly defined design requirements and is sensitive to price, it could use the traditional DB method and ask for a design-based proposal with a price. If, on the other hand, the owner team does not have a clear design preference at the outset and/or does not want to spend time and resources on predesign, it could select the appropriate team first and work with the team to use PDB to complete the project design.
The Design–Build Institute of America (DBIA 2017DBIA 2019) comprehensively introduces the PDB method and has provided a standard PDB contract (DBIA). This paper summarizes the major differences between the two methods by reviewing PDB procurement documents, with a focus on three aspects: solicitation process; contractual structure; and responsibility and risk allocation.
In the solicitation process, the owner no longer has to have a complete basis of design prior to team selection. The procurement process in traditional DB typically requires two phases: the RFQ phase, and the RFP phase. During the RFQ phase, the owner team creates a short list of design–builders after reviewing their qualifications. The team then creates an RFP from a baseline design with technical specifications. Once the RFP has been issued, the shortlisted design–builders submit a detailed technical proposal with a design sufficient to define scope and price (Migliaccio et al. 2009).
This two-part DB procurement process has a potentially negative impact on innovation, since it does not give the designer discretion over the whole design, and it assigns the owner more responsibility for the cost of changes. It also costs the owner more time and money upfront. PDB resolves these issues, since it requires the involvement of the DB team in the design phase from the very beginning. Because very little or none of the design is developed before a PDB contract is awarded, the streamlined procurement process of this alternative method allows the owner to save time and money. Usually, the PDB method reduces the procurement period by about 2 months, since proposers no longer need to develop a portion of the design to support their proposals. The resulting time and cost savings naturally attracts more teams to participate in the selection. Preparation costs for RFQs and RFPs are also relatively low in PDB, since the selected team wins primarily on the basis of qualifications. This qualification-based selection (QBS) makes the owner’s evaluation of the proposals relatively easy.
In terms of contractual structure, PDB projects usually have simpler contracts than traditional DB projects. Commonly, there are two separate contracting phases in a PDB project: preliminary agreement; and DB contract. The open-book preliminary agreement provides for hourly compensation of the selected team’s work to deliver a partial design and a design narrative sufficient to define scope and price. The targeted level of design is typically the traditional design development (DD) stage, but this can be set at any percentage of completion agreed upon by both parties. The DB contract is a separate contract based on the deliverables set out in the preliminary agreement. Its scope is similar to that of a traditional DB contract—in short, to complete the design and build the project at the agreed-upon price. Since the DD work (including the narrative) is both collaborative and incomplete, the owner’s concern about risk may be heightened by varying interpretations of the scope during the DB phase. Thus, owners familiar with traditional delivery methods (e.g., DBB) may feel more exposed to risks and/or uncertainties with any form of DB.
The DB contract in the PDB approach can be based on either guaranteed maximum price (GMP) or lump sum; and the level of design detail on which the price is based is typically higher in PDB (around 60%) than in traditional DB (approximately 35%). Under PDB, the collaborative design process continues after the preliminary agreement is awarded, since the design still has to be completed (with significant owner involvement). During this initial phase, the owner participates in decision-making on scope and design. Since the contract price has not been set, these decisions on scope typically include some trade-offs on the basis of subsequent cost estimates provided by the selected team as the design progresses. The owner can also use the project contingency to include additional scope elements that were not previously well defined. The open-book contractual terms allow for owner participation and flexibility in ongoing design, redesign, scope additions, reestimates, and value considerations (Migliaccio and Holm 2018). Under PDB, as the design and the project both progress, the DB contractor can procure subcontractor design assistance/bids and, thus, provide the owner with a firmer cost for the major elements of works (Loulakis 2013).
In PDB projects, the owner organization assumes a fairly large amount of responsibility and risk, due to its intense involvement in the entire process, especially the design phase. This increased risk load requires owners to be well informed regarding project needs and requirements. While PDB does not require the owner to have a rigorous basis of design in the RFP, having one can help simplify owner responsibilities during the design collaboration required for the preliminary agreement. A good basis of design in the RFP can be particularly valuable when multiple stakeholders within the owner organization have expectations that need to be met. It can also alleviate concerns about certain project characteristics being lost during the busy and typically time-constrained design phase.
To provide a comprehensive understanding of PDB and to contribute to best practices for future PDB implementation, this case study of a pilot PDB project included the following research activities: analysis of project documents; participation in project meetings; and performance of semistructured interviews with the project stakeholders (e.g., project owners and contractors).
In 2013, the University of Washington (UW) green-lighted a project to build the WCUP, a new facility that would serve as an extension of the university’s power plant. The WCUP was designed to produce chilled water to meet both process and comfort cooling needs for a variety of facilities in the West and South Campus areas of the University. The plant was also built to generate electrical power for emergency/standby needs.
Located on University Way near Pacific Street, the plant stands prominently as something of a “gateway” to the campus. Because of its “gateway” location, the WCUP was also designed with excellent building, architectural, and landscape elements (Figure 1). To better communicate the university’s sustainability goals, the WCUP includes a public messaging system to communicate the UW’s commitment to environmental stewardship and sustainability. Central to this sustainability messaging system is a series of 10-foot-tall light-emitting diode (LED) panels mounted inside the building’s large ground-floor windows. The LED screens play informative videos showcasing UW’s sustainability efforts, while the windows in between provide a glimpse at the equipment inside. The WCUP received an Envision Gold Certification after its establishment.
Fig. 1
A glimpse of the West Campus Utility Plant (picture from the UW Sustainability Web site).
The WCUP project was planned in two utility expansion phases. In the first phase, the project team was charged with building and putting into operation a plant containing generators, chillers, cooling towers, and associated equipment capable of producing 6MW of emergency power and 4,500 tons of chilling capacity. Because the planners foresaw the opportunity to approximately double both the power production and the chilling capacity in the second phase of the project (i.e., 12 MW of emergency power and 10,500 tons of chilling capacity), they designed the building with the space and specifications necessary to host both utility expansion phases.
Due to the potential changes to the West Campus in the future, the delivery of the WCUP project had to be flexible. In 2013, the State of Washington changed the Revised Code of Washington (RCW) 39.10.300 to make PDB implementation possible in public works. The WCUP project team built the facility using the highly collaborative PDB process, an approach that was new to both the university and the state.
The use of PDB on the WCUP project was preceded by a planning phase and followed by the implementation of the two-phase solicitation process (the RFQ and the RFP phases). Each phase was further divided into lower-level steps, and the milestones reached from one phase to the next were marked by the publication of a document. Team qualification was the only criterion used in the RFQ phase; expanded qualifications, the proposed project approach, and the legally required price-related factor were the criteria in the RFP phase. The DB team was chosen after the solicitation. The owner and the selected team then proceeded to sign two contracts concerning the completion of the design and the construction, viz., the preliminary agreement and the construction contract, respectively. Figure 2 illustrates an overall delivery process.
Fig. 2
Overview of procurement process with phase durations and milestones.
In this project, the planning phase happened before the solicitation. Project demands were identified at the outset by the UW Facilities Services (FS) department. Then, Capital Planning and Development (CPD), the organization responsible for managing capital projects at the UW, hired consultants to evaluate the feasibility of augmenting the campus emergency power and chilled water capacities at various sites. Based on the feasibility study, CPD and FS applied to the UW Board of Regents (BoR) for project authorization. This request set out the initial project budget, scope of work, and schedule. The BoR approved the authorization request in 2013 and allowed the use of PDB as the delivery method. Once approved, the WCUP project was then officially launched.
The solicitation process contained the RFQ and RFP sub-phases.
To determine project priorities and develop the risk management plan, the CPD contract/legal manager and directors performed a policy analysis. The RFP documents were developed after this initial policy analysis. The purpose of the RFQ was to generate a shortlist of possible DB teams, which, once in the running for the contract award, would have access to the RFP. The RFQ phase can be further divided into three major steps: (1) preparation of RFQ documents; (2) interaction with the prospective DB teams; and (3) evaluation of the statements of qualification (SOQs). Figure 3 presents a detailed illustration of the RFQ process.
Fig. 3
The RFQ phase.
In the first step, the project directors and managers were responsible for preparing an initial RFQ draft containing the weighted selection criteria and a description of the process. The CPD contract/legal manager and directors then solicited suggestions through an industry review (through the
Evaluation criteria used during the RFQ phase
| 1 | Technical qualification (e.g., technical skills and experiences) |
| 2 | Capability to perform the work (e.g., team’s organizational structure and management) |
| 3 | Financial capacity (as a pass/fail decision) |
| 4 | Relevant past performance (e.g., past experience of the similar projects) |
| 5 | Design excellence on a limited budget and schedule (e.g., examples of achieving high levels of quality for projects respecting time and budget) |
| 6 | Safety (e.g., the past safety records and accident prevention plans) |
In the second step of the RFQ phase, each competing team used the RFQ to develop its SOQ. Unlike other projects, the WCUP owner held no collective meeting to interact with the competing teams. However, any team requesting clarification could consult with a representative assigned by the owner.
In the evaluation step, the participating teams submitted their SOQs within the prescribed time limits to the selection committee (SC). The SC was composed of seven members, including three representatives from the UW FS, two from the CPD, and two from the Office of the University Architect. The SC evaluated the SOQs by assigning point scores to each criterion. Once the points had been added up, the three highest-scoring teams were shortlisted and invited to participate in the RFP phase.
As is characteristic of a PDB project, the shortlisted teams were not required to design or price an actual proposal. The WCUP project emphasized that the participating team should instead focus on proving its members’ qualifications and its approach to collaboration. As in the RFQ phase, the RFP also consisted of three steps: preparation of the RFP package; proposal development; and proposal evaluation and selection. Figures 4 through 6 illustrate the processes of these steps in detail.
Fig. 4
The preparation of RFP.
Fig. 5
Proposal development.
Fig. 6
Proposal evaluation.
The owner first prepared the RFP package to clearly express the requirements and expectations. The package contained the following components: a) RFP document; b) price factor form; c) two contracts (the first and the second agreements); d) general conditions; and e) general requirements. The RFP document emphasized its requirements for a high-level basis of design. These qualifications-focused design requirements were relatively vague compared to those of a traditional DB RFP. The document also prescribed the procedures and set the deadlines for submitting the proposals; and it also provided an explanation of the evaluation process, including the evaluation criteria and their corresponding weights. Table 2 summarizes the main criteria.
The main proposal evaluation criteria in the WCUP project
| 1 | Essential characteristics of, and general approach to, managing the DB project (e.g., the understanding of the PDB method) |
| 2 | Engineering approach (e.g., the team’s strategy to develop the project in terms of functionality and quality of the work) |
| 3 | Approach to building architecture and urban design (e.g., how to stick to the UW architectural goal) |
| 4 | Management and approach to design development (e.g., the means of interaction within the team and between the team and owner during the design) |
| 5 | Management and completing approach to design and construction (e.g., how changes during the project design and construction will be managed) |
| 6 | Management and approach to commissioning and training (e.g., how the team will train the UW staff to allow the smooth transition to operations) |
| 7 | Ability to meet time and budget requirements |
| 8 | Acceptance of contract, bonding, and insurance (as a pass/fail decision) |
| 9 | Workload factor (e.g., impact of activities outside the project that may affect the team’s ability to carry out the work) |
| 10 | Location of the team (as it may affect the communication capability during the work) |
| 11 | Price factor, including the percentage rate for overhead and profit of the DB contractor |
| 12 | MBWE (minority- and women-owned enterprise) outreach plan |
Of the criteria summarized in Table 2, the owner team considered the first six of greater importance and assigned them heavier weights. Although not assigned a heavy weight, Criterion 11, the price factor, provided a banding element of the price to be provided by the winning team in the second contract. The team was not permitted to change, at a later point, the percentage it provided for this criterion. Once the preparation step had been completed, the RFP package was released to the three eligible candidates.
During proposal development, the owner scheduled individual meetings with the shortlisted teams, referred to as proprietary meetings, to help each one get any necessary clarification on the evaluation criteria and/or the selection process. In these meetings, the shortlisted teams had the opportunity to present their preliminary proposals and communicate with the university’s architectural commission, the SC, and other executives. The owner posted pertinent addenda on the Web site to ensure that each team competing had the same amount of information.
In the evaluation step, the shortlisted teams submitted their proposals in two different envelopes, one containing their bonding/insurance letters and the price factor they had calculated, and another containing their responses to the remaining criteria. The owner team controlled whether proposals were submitted on time, collected the completed proposals, discarded incomplete proposals as well as the teams that the independent financial consultant adjudged as failing to meet Criterion 8 (P/F), and then forwarded the eligible team proposals to the SC for scoring and ranking. The winning team was determined solely on the basis these evaluation scores.
This phase started with a negotiation between the owner and the winning team and was followed by the execution of the preliminary agreement. This agreement required the owner and the DB team to collaboratively formulate a work plan to include the following elements: (1) a scope of work and a schedule of activities; (2) the anticipated hours needed to complete each activity; (3) a list of the individuals who will be responsible for each activity and their corresponding hourly rates; and (4) the deliverables, i.e., approximately 60% design, with a design narrative and a price. The terms of the preliminary agreement prescribed time and materials not to exceed a maximum amount, unless adjusted by mutual agreement between the owner and the contractor. If the owner and the highest-scoring finalist failed to reach an agreement on the contract, the agreement stipulated that the owner could then choose to enter into negotiations with the next highest-scoring finalist.
The second contract dealt with the completion of the design and the construction phase, and it was structured as a lump-sum agreement. The process allowed for two different scenarios to unfold in this phase. In the first scenario, the owner and the DB team that had signed the preliminary agreement would further agree on and sign the second contract and, then, complete the project design and construction collaboratively; however, in the second scenario, if the owner and the original team failed to reach an agreement on the final project price or any other terms in the second contract, the owner could use alternative approaches to complete the project. If the second scenario came to pass, the preliminary agreement allowed the owner to keep all the purchased design work provided by the original team, hire another team to complete the remaining work, or execute the project with another delivery method such as DBB. In this project, the owner continued to work with the original DB team to complete the project under PDB. Figure 7 illustrates the steps of the two contracting phases in detail.
Fig. 7
The contracting process in the WCUP.
For the WCUP project, the owner (the university) selected a DB team composed of the following organizations in the following capacities: a) Mortenson Construction as the contracting entity and constructor; b) Miller Hull as the architect; c) Arup as the major engineering team; d) Gustafson Guthrie Nichol as the landscape architect; e) KPFF Consulting Engineers as the civil engineer; f) Landau as the environmental engineer; and g) other independent consultants. Strictly speaking, because of their proximity to the project site, the project parties did not need to establish a colocation venue. (Both Miller Hull and Arup had offices in downtown Seattle, while Mortenson had one in Kirkland.) But, since communication and coordination are so critical to a PDB project, they usually met at the Arup offices when necessary.
As the diagram of the project’s organizational chart in Figure 8 shows, the WCUP project was managed from the owner’s side by the CPD staff. Having obtained its authorization from the UW BoR, the CPD assigned the project manager from among its ranks.
Fig. 8
The WCUP organizational chart.
For this project, the project manager was selected from the Major Project Group (MPG), a specialized group within the CPD, responsible for projects with a total cost of $10 million or greater. Once assigned, this individual served as the main point of contact throughout the project life cycle and worked closely with the construction entity to ensure adherence to schedule and budget. The project manager was responsible for organizing and administering the project from conception to completion. Other participants on the owner’s side included a number of consulting firms and experts. In the solicitation phase, the following consultants participated: URS (now AECOM); HSKS Architecture; Geo Design; and a financial consultant. In the construction phase, the hired consultants were URS, JMB, NRC, Mayes, and Geo Engineer, among others.
On the DB team side, Mortenson led the team, having contracted with Miller Hull for architectural services and with Arup for engineering design. Moreover, as the general contractor, Mortenson also contracted with the major mechanical and electrical subcontractors, as well as with all other subcontractors on the project. So, although the designers worked with the owner in the collaborative PDB atmosphere, they had all contracted directly with Mortenson.
As the first PDB project undertaken by UW and the State of Washington, the WCUP delivered successful outcomes in terms of schedule, budget, and collaboration. Overall, stakeholder feedback conveyed positive reactions to the PDB process. By successfully communicating good faith and building mutual trust, the owner and the DB team established and maintained healthy relationships among all project participants. No hard disputes emerged during the project delivery period, and the process of resolving issues with contractors and subcontractors worked efficiently.
Still, the project did encounter some issues of concern during the process. From the owner’s perspective, while the design and collaboration process was generally rigorous, the cost-estimating process did not work as effectively as anticipated. For example, different stakeholder groups were expected to collaborate with the design professionals in their respective areas of concern or expertise, but this fragmented approach caused the overall design process to be less inclusive and efficient.
The research team drew the lessons learned from the planning, solicitation, and execution phases of the WCUP project, as well as from some of the findings of the literature review. As the project proceeded, the research team members performed an extensive review of relevant published research and source documents on PDB. Moreover, they conducted interviews with the project stakeholders to identify current practices related to PDB. Additionally, in order to improve the future use of the PDB delivery method, the WCUP owner held a conference on lessons learned from the project before its final completion. The research team recorded and summarized the conference findings, and these findings are present here separately, as follows:
While PDB is flexible enough to allow an owner to get the DB team on board before the basis of design has been substantially developed, having a meaningful predesign and using it as a benchmark to establish reliable scope and budget alignment before RFQ issuance is likely to prevent confusion and promote efficiency in the collaborative design phase. Moreover, it will serve as a meaningful measure of the “big picture” success of the project.
To the degree that the basis of design remains undeveloped and the project budget rests on a rough estimate, the owner should manage the expectations of the approval/funding authority by emphasizing the need for further scope and budget alignment; however, if discovery of unexpected circumstances indicate that the costs of achieving the owner’s original goals exceed the project’s funding capacity, the owner should be prepared to cancel or fundamentally redefine the project. PDB can engender this fundamental problem by enabling the project to start with less preparation than other delivery methods require. Thus, this capacity is a double-edged sword: while its potential for efficient collaboration can provide an invaluable advantage in normal circumstances, the approval/funding authority must be fully cognizant of the risk entailed and the intricate coordination sometimes required, especially in the public sector. If the owner proceeds assuming such risks, the RFQ should express the potential for project redefinition.
The owner team can minimize the price-related factor by assigning it relatively little weight in the proposal evaluation process, thereby allowing the overall process to approach QBS. This treatment is generally appropriate since there is no design or value proposition to evaluate, but proposers may push the limits of what is reasonable just to capture the advantage of the few points attached to this criterion. To arrive at the price-related factor, the WCUP used the candidates’ overhead and profit as a percentage of the direct construction cost and thereafter included a method of comparing them and assigning points in the RFP. The lowest number (winning percentage) was quite favorable to the owner, and the entire approach was generally successful; but the winning team can end up in a situation that is so constrained that bringing resources, transparency, and collaboration may be more difficult than is healthy for the project. While the owner team naturally wants low numbers, it also wants the best teams to compete for the current and future projects. Thus, minimizing the influence of the price-related factor on the selection process is appropriate for PDB.
The competing DB teams should spend more time to determine the design team. Although the RFP appropriately did not focus on design, its lack of detail impeded team formation. To ease this difficulty in other projects, an owner can dictate the composition or “depth” of each team responding to the RFQ. Several considerations may drive this aspect of the solicitation process. Restricting the disciplines to contractor and architect, for instance, enables team formation with greater owner influence and fewer market restrictions (for more creativity). On the other hand, leaving proposed team depth open to the discretion of the market (i.e., primarily up to the DB teams) promotes integration and innovation very early, eliminates some later procurement work, and increases the range and nature of the owner’s choices during the selection process. The WCUP project left the team composition open to market discretion and, although the proposals varied, it was not difficult to compare them. At the project’s end, the five firms on the selected team found this approach to be very effective. Thus, leaving the team depth open to market discretion can work well. The flexible DB team composition also exposed new but innovative players to the owner and gave them a chance to increase their market share.
Proprietary meetings are valuable in that they help DB teams understand the RFQ/RFP criteria of PDB projects. Since a PDB RFP does not make the quality of the design work a criterion, these meetings enable the competing DB teams to discuss the selection criteria that are included in the RFP. Moreover, the owner team can use these meetings to clarify its intent and interact in person with the DB teams.
While the architectural commission was and will continue to be an important player in the selection phase, its involvement should be strategically structured for more effective involvement. Since its participation in UW projects was originally established for projects delivered through the DBB method, the process for its involvement in the WCUP project required hasty modifications that were only partially effective.
PDB lowers the cost of pursuing contract awards, compared to the selection process for a traditional DB project. Keeping design work out of the selection process clearly reduces the financial risk of the participating DB teams. Because this feature of PDB will naturally attract more qualified candidates and, thus, increase competition, its potential for project quality improvement is also good from the owner’s perspective.
The demand on PDB projects for wider collaboration through a system of meetings may have required more of owner effort than anticipated. The larger a meeting gets, the less effective it becomes; and smaller meetings proved to be much more effective on the WCUP project. Additionally, meetings on the WCUP project needed more structure to capture the owner’s comments and directions.
The DB team found that it did not need to invite the owner to all meetings, and sometimes the owner’s presence decreased efficiency. For example, in this project, had the DB team sometimes met without the owner, it could have forgone making the report-outs required in meetings with the owner. Since these report-outs are time consuming and sometimes not necessary, some meetings could take less time and address pressing issues more efficiently without the owner’s presence.
Real-time feedback from the estimating teams will improve the decision-making process. Indeed, the estimating team should attend every meeting, to provide timely feedback on any changes to the project made during meetings.
After DB team selection, although the owner team tells the selected team to disregard the RFP and take a fresh look at the entire project, the team should still have performed a good baseline validation of the scope set out in the RFP.
By understanding the content, assumptions, and nuances of the estimating process and its deliverables, the designers got a better grasp of the associated design constraints and showed empathy for the cost constraints identified.
Project constructability improves as a result of the high-level collaboration of design and construction professionals during the preliminary agreement phase.
To facilitate an efficient design review and approval process, owners should actively participate in the design work, along with dedicated and knowledgeable staff.
Public owners may feel compelled to use a method that is “transparent and allows the market to speak”. Because PDB almost entirely uses QBS, it may be criticized in this regard. However, there are mitigating considerations. Onboarding of major trade partners (contractors) during the preliminary agreement phase can generate scope/value competition. The owner can see the inner workings of the pricing build-up and negotiate before establishing the terms of the second contract. The owner can also have a third party review the scope and pricing results from the preliminary agreement phase and can use a GMP contract (although the WCUP project used lump sum). Furthermore, what the “market” says at the beginning of a project (i.e., on bid day) is often different than what the owner ultimately spends; and PDB has the potential to provide excellent value.
Workforce continuity is an essential ingredient for project success and should be prioritized because of the value of long-time workers’ accumulated knowledge. When people must be replaced or when influential new players must join the team, the project team should provide them with an orientation that emphasizes the nontraditional aspects of PDB and the particulars of the project to date. This information should include the contours of the partnering agreement, the nature of change management (with a focus on roles and responsibilities), and the participation of incumbents from all stakeholder groups. From planning and design to commissioning and operations, the project team should not lose sight of the importance of continuity and thorough onboarding.
When the price was locked, every participant needed to understand the gaps; and it was better when those gaps were well defined, to ease end-user concerns regarding the project.
The collaborative design phase constituted a major “journey of discovery”, with large changes being possible, but it was also time consuming. In the face of such changes, the owner had to consider the potential impacts of such delays on the quality of the deliverables set out in the preliminary agreement and then had to adjust wisely even when the team wanted to proceed heroically. The entire PDB process is a journey, and expectations should be set accordingly. Because it is a flexible and collaborative delivery method, problems can be overcome; but some of the risks are somewhat different in character than those assumed in other delivery methods (as are some of the opportunities available to manage them). If large changes occur, it may be worthwhile to reindoctrinate the entire project team into the new set of expectations, or the project may be saddled with unnecessary baggage.
Scope (including design details and quality issues) would have been easier to align with budget constraints if the alignment process used during the preliminary agreement phase had occurred earlier and been more thorough.
Early on, the project had limited success in getting subcontractors on board. Using PDB on a project allows a project to begin with less drawings while creating the need for more coordination later on at the shop drawing stage; the deviation of this approach from standard practice may make a PDB less attractive for many specialty contractors.
The flexibility of PDB gave the WCUP project agility and fast reaction time during the construction phase, and the lump sum contract limited the owner’s exposure to financial risk.
To increase trust, owner representatives (e.g., the project manager) should be able to see the issue log so that they can see which issues are being caught and how they are being handled.
Owners must drive construction-phase participation to a higher degree. For example, owners should step up and do their own assurance.
As an emerging alternative to the DB project delivery method, the PDB method provides for the selection of the DB team prior to setting the project program and/or budget. PDB allows for the selection of the DB team, mainly on the basis of qualifications and with a limited price consideration. In order to have a comprehensive understanding of PDB, the research team conducted a case study based on the first PDB project executed by the University of Washington and the State of Washington, viz., WCUP. This paper has summarized this project’s entire delivery process (e.g., planning, solicitation, design, and construction), organizational structures, and outcomes. It also presents the lessons learned from the project. The findings on the WCUP project are presented here to contribute to best practices for future PDB implementation.