Quality Assurance in Design-Build Projects (2008)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

5SYNTHESIS OBJECTIVE The objective of this synthesis is to capture the various ways in which quality assurance (QA) is handled in design-build (DB) projects. The synthesis identifies different approaches, models, and commonly used practices, recognizing the dif- ferences in each of the different delivery methods. The syn- thesis also addresses how the core principles of QA can be satisfactorily addressed in DB projects. It applies these prin- ciples from the procurement phase to both the design and construction phases to cover the entire life cycle of a DB project. In addition to a rigorous literature review, the syn- thesis is based on new data from two sets of surveys and two content analyses. A general survey on DB quality manage- ment provided 76 responses from 47 states. A content analy- sis of DB solicitation documents from projects with a total contract value of more than $11.5 billion from 26 trans- portation agencies across the country was also conducted. For further verification, an additional content analysis of DB policy documents from 17 states was conducted and the data were collected from a brief survey on DB quality percep- tions from 17 states. DESIGN-BUILD BACKGROUND The Design-Build Institute of America (DBIA) predicts that 50% of nonresidential construction projects will be delivered using DB in 2010 (Eby 2005). This tracks well with a 2004 survey that found that construction companies expect 50% of their revenues to come from DB projects in 2006 (Zweig- White Research 2004). This same study reported that 80% of all design and construction firms surveyed in the United States expect the percentage of their business derived from DB projects to increase over the next 5 years. Figure 1 shows that the percentage of nonresidential construction projects being delivered by DB has increased steadily over the past 20 years from an estimated $18 billion in 1986 to more than $250 billion in 2006 (Design-Build Institute of America 2005). This shift in project delivery culture first began in the 1960s in the private sector on commercial construction pro- jects with strong revenue streams where the financial benefit of compressing the project delivery period outweighed the risk of starting construction before the design was totally complete (Gransberg et al. 2006). In the 1980s, it spread to the public sector as a method for delivering revenue-producing projects, such as toll roads and bridges, as well as an effective means to expedite the procurement of emergency recon- struction after natural disasters, such as the Interstate bridges demolished by hurricanes in Florida. In 1996, the Federal Ac- quisition Reform Act was passed and specifically provided both regulation for the use of DB on federal projects and the authority to utilize the delivery method without seeking spe- cial permission (Gransberg et al. 2006). Since its inception in 1993, DBIA has tracked state and federal capital project and infrastructure procurement laws regarding DB. It has documented the trend of expanded leg- islative authority to public-sector engineering and construc- tion agencies to legally use DB in all types of construction procurements. The building sector has led the infrastructure sector in terms of embracing the use of DB. States such as California and Oklahoma have authorized its use on public buildings without extending broad DB authority to their departments of transportation (DOTs). Nevertheless, in the past decade, DB transportation projects have been con- structed in more than 35 states. Some are restricted to toll projects or mass transit projects in which the revenue gener- ation potential forms a convincing argument for achieving an early opening by compressing the traditional delivery period to its shortest state. Thus, the use of DB project delivery in the transportation sector is growing across the country. DESIGN-BUILD IN TRANSPORTATION By 2004, the FHWA had approved more than 300 DB trans- portation projects worth nearly $14 billion in 32 states under the FHWA Special Experimental Projects program (SEP- 14) (SEP-15 Program 2006). Figure 2 shows the status of SEP-14 project approvals as of 2002. By 2002, the Florida DOT alone had awarded 49 DB projects for nearly $500 mil- lion worth of work and estimated that DB cut the traditional project delivery period by 30% (Peters 2003). When one adds the uncounted number of public building, utility, and other infrastructure DB projects completed by county and municipal public agencies as well as the public-private part- nerships (PPPs) that deliver critical infrastructure such as toll roads, toll bridges, and water and wastewater projects, the nationwide market for DB project delivery is truly stag- gering. To generate such meteoric growth in such a short pe- riod vividly confirms that DB must accrue tangible benefits to the public agencies that implement it. FHWA eloquently CHAPTER ONE INTRODUCTION

6FIGURE 1 Design-build growth in the United States (Design-Build Institute of America 2005). FIGURE 2 SEP-14 DB project approvals as of December 2002 across the United States (Design-Build Effectiveness Study . . . 2006). articulates the motivation for implementing DB when it states that: The greatest motivation and realized benefit to a contracting agency of using design-build . . . is the ability to reduce the overall duration of the project development process by elimi- nating a second procurement process for the construction con- tract, reducing the potential for design errors and omissions, and allowing for more concurrent processing of design and construction activities . . . (Design-Build Effectiveness Study . . . 2006). Design-Build Controversy The emergence of DB contracting on the national transporta- tion scene has certainly been controversial. The emotions associated with the paradigm shift required to implement it have run high. When it emerged in the late 1980s, its detrac- tors consisted primarily of the professional societies associ- ated with the design industry who argued that the use of DB would inevitably degrade the ultimate quality of the constructed product by compromising the integrity of the design process. This fear was expressed in the National Society of Professional Engineers Position Statement #1726 that stated: Design decisions may be determined or inappropriately influenced by team members other than the designer. This is more likely to occur when a non-designer is the lead on the design-build team. The leader may pressure designers to reduce self-imposed quality criteria or design standards to minimum levels in order to maxi- mize profit (“Design/Build in the Public Sector” 1995). This confirms the need for a study like this synthesis to assist public transportation agencies in determining an appropriate distribution of responsibility for quality man- agement in a DB transportation project and how to commu- nicate this distribution effectively in DB solicitation documents. Many factors will independently influence the outcome of any construction project; “however, perfor- mance can be significantly influenced by the system employed to ensure quality” (NCHRP Synthesis of Highway Practice 65 . . . 1979). To transfer design liability effectively to the design-builder, a DOT must also transfer many of the traditional QA responsibilities as well. This leads to a con- cern that the “fox may be guarding the hen house,” as cap- tured by the preceding statement. A study by Ernzen and Feeney of the Arizona DOT’s DB program (appropriately titled “Contractor-Led Quality Control and Quality Assur- ance Plus Design-Build: Who Is Watching the Quality?” 2002) addressed this concern directly by comparing project

7QA test data on a DB project in which the design-builder had been assigned the responsibility for QA with data from a similar project delivered by traditional means. The study found the following: Analysis of the data shows that despite a highly compressed schedule, the quality of the material on the project exceeded the project specifications and was similar to the quality of work completed for the state under traditional contracting methods with an Arizona DOT-operated quality assurance program (Ernzen and Feeney 2002). The Arizona DOT study and the numbers for DB growth previously cited regarding the growth in DB across the nation effectively belie the theory that implementing DB project delivery will inherently result in decreased construction qual- ity. It would be difficult to believe that sophisticated public owners, such as state DOTs, would propagate the spread of a delivery method that consistently resulted in substandard or poor-quality product regardless of its ability to expedite project delivery. There have, however, also been recent studies done by Turochy and associates that show a statistically significant difference in test results for hot-mix asphalt mat compaction between contractors and the state DOT (Turochy et al. 2006; Turochy and Parker 2007). In the first study, done using Georgia DOT data comparing DOT QA tests with contractor quality control (QC) tests, the differences in the variances in the majority of cases were statistically significant, although the differences in means were not (Turochy et al. 2006). In a later study analyzing data from Alabama, Florida, Kansas, and North Carolina, the authors found that “standard devia- tions for the contractor test results are always smaller than agency counterparts, and usually significantly so from a sta- tistical perspective” and that “contractor test results are al- ways more favorable (i.e., larger) than agency test results” when examining the differences in means (Turochy and Parker 2007). These authors concluded that “the consistent indications of less variable and more favorable contractor test results, relative to specification limits, are compelling reasons to consider limiting the use of contractor-performed tests to quality control,” while recognizing benefits to having contractors perform QA on their products (Turochy and Parker 2007). Even though these studies have conflicting conclusions, DB project quality was approximately equal to the quality found on the design-bid-build (DBB) projects in both cases. The FHWA Design-Build Effectiveness Study reports actual results that conclusively confirm this belief, as summarized in the following quotation: On average, the managers of design-build projects surveyed in the study estimated that design-build project delivery reduced the overall duration of their projects by 14 percent, reduced the total cost of the projects by 3 percent, and maintained the same level of quality as compared to design-bid-build project delivery (Design-Build Effectiveness Study . . . 2006, italics added). Culture Shift for Quality Assurance in Design-Build The need for this synthesis is a consequence of both contin- ued growth and the need for a better definition of QA in the DB context. All DB projects must be delivered with at least the same level of quality that occurs in DBB. In traditional DBB contracting in the transportation industry, decades of QA and QC experience provide a wealth of knowledge and standard practices that are readily accessible and widely ac- cepted for assuring quality on infrastructure projects. In DB, however, there exists a limited but rapidly expanding body of experience associated with assuring quality. The purpose of this synthesis is to bring together this relatively new body of experience and summarize it in one easily accessible refer- ence on QA in DB projects. The authors realize that not all topics are fully developed and recognize the limitations placed on a summary report. One of the major challenges facing DOTs and design- builders in implementing DB is the change that must take place in the culture of both parties. This is well described in an evaluation report given on the I-15 DB project in Utah. The Owner felt that one of the biggest challenges to the QC and QA program was “breaking the mold” of the traditional roles of the contractor and Owner. The Owner’s personnel had all come from the “catch and punish” culture. Likewise the Contractor personnel came from a similar background. To change philoso- phies to a more proactive quality role by the Contractor and a less controlling oversight role of the Owner was a significant challenge. Most personnel assigned to the project by either party had worked under traditional systems for many years and this was the first experience with this type of project (Postma et al. 2002). As both DOTs and design-builders become more familiar with DB, the culture change will be less of an issue. Another issue that has confronted DB projects since their implementation has been the idea that contractors, who take the lead in many DB projects, would pressure the designers, who are often a subcontractor, into sacrificing quality for higher profits. According to the Design-Build Effectiveness Study mentioned earlier (Design-Build Effectiveness Study . . . 2006) this has not been the case. However, having a well- defined quality management system is one way to address some of these fears. This is even more important on high- profile projects that are delivered using DB. A quality manage- ment system adds credibility and assurance for all involved— from the contractors, to the DOT, to the public users (Panta- zides 2005). KEY DEFINITIONS In reading this synthesis, it is important that the vocabulary associated with the assurance of quality is clearly under- stood. Throughout the construction industry, there are certain terms that are used to define aspects of quality programs. The

8literature review revealed what is best described as “confu- sion” among the various authors as to precise definitions for the various aspects of “quality” and the terminology used to describe the tasks involved in construction quality manage- ment. The American Society for Quality defines quality as “the totality of features and characteristics of a product or service that bears on its ability to satisfy given needs” (“Quality Glossary” 1998). That definition is quite broad, but the focus on “satisfy given needs” is cogent to this section. The owner must clearly articulate the “given needs” for design and construc- tion quality in the DB project request for proposal (RFP). One way to do that is by requesting specific quality-related submittals as a part of the DB proposal. The other way is to include the requirements for design and construction quality management as submittals required after contract award. The American Society for Quality goes on to define five varying types of quality as follows (“Quality Glossary” 1998): • Relative quality: Loose comparison of product features and characteristics. • Product-based: Quality is a precise and measurable variable and differences in quality reflect differences in quantity of some product attribute. • User-based: Fitness for intended use. • Manufacturing-based: Conformance to specifications. • Value-based: Conformance at an acceptable cost. Thus, it can be seen that the concept of quality has many facets. As a result, an owner attempting to articulate the re- quirements for both design and construction quality needs to be very precise in the working definition of quality for each feature of work. One way to measure quality is by confor- mance to a quality plan (Arditi and Lee 2004), a topic that is addressed in chapter three. Standard Definitions For the purposes of this report, the Transportation Research Circular E-C074: Glossary of Highway Quality Assurance Terms (2006) is used to define the QA terms. The major def- initions are cited here. • Quality—(1) The degree of excellence of a product or service; (2) the degree to which a product or service sat- isfies the needs of a specific customer; or (3) the degree to which a product or service conforms with a given requirement. • Quality assurance—All of those planned and system- atic actions necessary to provide confidence that a prod- uct or facility will perform satisfactorily in service. (QA addresses the overall problem of obtaining the quality of a service, product, or facility in the most efficient, economical, and satisfactory manner possible. Within this broad context, QA involves continued evaluation of the activities of planning, design, development of plans and specifications, advertising and awarding of con- tracts, construction and maintenance, and the interac- tions of these activities.) • Quality control—Also called process control. Those QA actions and considerations necessary to assess and adjust production and construction processes so as to control the level of quality being produced in the end product. • Independent assurance (IA)—A management tool that requires a third party, not directly responsible for process control or acceptance, to provide an indepen- dent assessment of the product and/or the reliability of test results obtained from process control and acceptance testing. (The results of independent assur- ance tests are not to be used as a basis of product acceptance.) • Acceptance plan—An agreed-upon method of taking samples and making measurements or observations on these samples for the purpose of evaluating the accept- ability of a lot of material or construction. New Definitions for Design-Build Environment To these definitions the report adds two that are not contained in Transportation Research Circular E-C074: “quality man- agement” and “project quality assurance.” Transportation Research Circular E-C090 recognized the need for new definitions for quality in DB projects and noted that: As it relates to QA, the owner is responsible for oversight man- agement and a new definition of QA. This new definition includes oversight to provide confidence that the design-builder is per- forming in accordance with the QC plan, design monitoring and verification through auditing, spot-checking, and participation in the review of the design (Warne et al. 2006, italics added). Quality management is defined as follows: The totality of the system used to manage the ultimate quality of the design as well as the construction encompassing the quality functions described previously as QA, QC, IA, and verification. Defining a quality management system was simplified in a previous report to the following four basic questions that provide a concise reference to ensure that a quality manage- ment system is fulfilling its needs (NCHRP Synthesis of Highway Practice 65 . . . 1979): 1. What do we want? 2. How do we order it? 3. Did we get what we ordered? 4. What do we do if we don’t get what we ordered? Project quality assurance (PQA) is defined as all those ac- tions necessary for the owner to ensure that design-builder- performed QA activities give a true representation of the quality of the completed project. This may include owner verification and acceptance testing or IA as owner oversight actions when the design-builder is assigned the

9responsibility for design and/or construction QA activities. Additionally, these also include owner oversight, verifica- tion, validation, acceptance, and other activities necessary to satisfy FHWA Technical Advisory 6120.3 (Use of Contrac- tor Test Results in the Acceptance Decision . . . 2004) for projects with federal funds and the employment of indepen- dent quality consultants that may be necessary in DB projects with post-construction operations and/or maintenance options. Project Quality Assurance Model Figure 3 is a graphical representation of the DB PQA model. The shaded area represents the universe of QA requirements that exist during both the design and construction phases of a DB project. In this form, it makes no specific assignment of QA/QC roles and responsibilities between the owner and the design-builder. The owner is free to make those assignments to whichever entity is best suited to carry them out in a satis- factory manner. The model shows that no matter who actu- ally performs the classic design and construction QA/QC tasks, at some point the owner must make a business decision as to whether or not to accept the completed design product and the finished construction product. In the case of design, this decision is indicated when the owner agrees to allow the completed construction documents to be “released for con- struction.” In construction, this decision is indicated when the owner agrees to make final payment, and when both these decisions have been made, the DB project is accepted. The details associated with the making of these two decisions contribute to the DB project’s acceptance plan as defined in Transportation Research Circular E-C074. For purposes of this report, the acceptance plan uses the definition proffered by Burati in a FHWA report on QA specifications. The acceptance plan will “be considered to represent only those functions associated with acceptance” (Burati et al. 2003). Along the way, the owner may use some form of IA to provide information that will assist him or her in making the design and construction acceptance decisions. In design, IA could take the form of sending portions of the design to an- other design professional for peer review before releasing it for construction, and in construction, IA could involve sam- pling and testing to statistically validate the design-builder’s QA and QC testing programs. Finally, PQA also encom- passes the less formal activities in which the owner engages to facilitate the design-builder’s progress. DB project deliv- ery demands a rich flow of technical information between the owner and the design-builder (Beard et al. 2001) and, as a result, owners have developed mechanisms to satisfy this requirement. One such activity has become known as “over- the-shoulder” design reviews (these are discussed in detail in chapter four). The Minnesota DOT (MnDOT) defines these as follows: The over-the-shoulder reviews are not hold points that restrict the progress of design. They are simply reviews of the design as it progresses and opportunities for MnDOT to provide comments and feedback on the design (Addendum 5 Project Management Book 2B . . . 2005). Another example of the types of activities that fall into the PQA universe was found in the Virginia DOT’s DB guide (Quality Control, Quality Assurance . . . 2007), which de- fines two new quality management roles beyond QA and QC and calls them “owner independent assessment” and “owner independent validation.” They are defined as follows: • Owner independent assessment—Oversight performed by the department (or agent) to satisfy Virginia DOT and FHWA requirements for documenting that proper QC and QA are being performed. This oversight pro- vides an independent assessment of design-builder’s FIGURE 3 Design-build project quality assurance model.

10 implementation of and compliance with the approved QC and QA plan. • Owner independent validation—Oversight performed by the department (or agent). The focus of owner inde- pendent validation is to verify design-builder’s QC and QA compliance and confirm that the quality character- istics of the products incorporated in the project are valid for acceptance and payment. QA in DB is currently developing. The same universe of responsibilities exists in DB as in DBB. The difference lies with who holds the responsibility. This report looks at this question and presents generic quality management organiza- tions found in the content analysis. Although there is no consensus among the various entities that use DB as to a rec- ommended or preferred QA organization, all DOTs have shifted more of the quality responsibility to the design- builder than is typically seen in DBB. SYNTHESIS METHODOLOGY This report is the result of an intersection between a compre- hensive literature review, a national survey of both public and private organizations with DB experience, and a content analy- sis of a large sample of DB RFPs. This methodology allowed for the collection of information on DB QA policies and pro- cedures across the nation by means of the standard survey, as well as the confirmation of those findings through a rigorous analysis of DB solicitation documents. The literature allows the findings from the other research instruments to be put in a global context to identify trends and similarities and capture the state of the art in the more general topic of alternative proj- ect delivery method quality management. The triangulation of these three methods allows for the development of emerging commonly used practices in this area to be identified. Before a description of the details of the report methodol- ogy is presented, the relative importance of the various research instruments should be understood. Because DB project delivery is still relatively new to the U.S. transporta- tion industry and only a handful of states have more than 5 or 6 years’ worth of experience, the importance of the general survey responses is less than would normally be expected in a typical NCHRP synthesis report. Because most of the sur- vey responses can best be characterized as anecdotal, the study went beyond the typical synthesis literature review and survey to conduct two content analyses of DB solicitation documents and DB policy documents. These analyses helped develop lines of converging information with the literature review and the survey responses by furnishing a quantitative analysis of how DOTs are actually applying QA to the DB project delivery process. The analyses provided a valuable insight into the best value procurement process as well as into various ways in which quality management organiza- tions are being fielded on various types of DB projects. Thus, the study gives the greatest weight to the output from the con- tent analyses as it intersects with the literature review and uses the survey responses to validate conclusions drawn by those intersections. Study Instruments Two of the study instruments used in this synthesis consisted of content analyses of DB solicitation documents and state DOT DB policy documents. These content analyses involved gather- ing and reviewing solicitation documents and searching for the requirements of QA and QC programs that were outlined in the documents. The first formal content analysis furnishes quanti- tative measurements of DB RFP requirements for QA and QC elements. These measurements are found by counting the num- ber of times that QA and QC terms are either expressed by the owner in the RFP or required to be submitted in the design- builders’ proposals. This type of analysis can be used to de- velop “valid inferences from a message, written or visual, using a set of procedures” (Neuendorf 2002). The primary approach is to develop a set of standard categories into which words that appear in the text of a written document (in this case a DB RFP) can be placed and then the method utilizes the frequency of their appearance as a means to infer the content of the document (Weber 1985). Therefore, in this study, the content analysis consisted of two stages. First, all instances of the word quality were found in each document and the context was recorded. Second, that context was used to determine, if possible, to which party in the contract the responsibility for quality in a given context was assigned. This allowed an inference to be made regarding the given owner’s approach to quality man- agement for a particular project. When the results are accumu- lated for the entire population, trends can be identified and reported. This method was then repeated with other terms that were common to quality management, such as verification and assurance, and the context was recorded and then analyzed. This process was repeated for the formal content analysis of the DB policy documents. The output from the two content analyses can then be compared with each other to determine how DB policy is being implemented in the DB solicitation documents. The output can also be compared with the responses from the two surveys that are discussed in detail later in this chapter to map respondents’ output against their respective state DB policy and DB solicitation documents. The use of these instruments in conjunction with the compre- hensive review of the literature allows the team not only to maintain a high level of technical rigor in the study but also to follow Yin’s three principles in the process of data collection (Yin 2004): 1. Use of multiple sources, 2. Creation of a database, and 3. Maintaining a chain of evidence. During the effort, the team was careful to remember that single sources provide limited data based on “one specific source” and can create difficulty when drawing results, in ad- dition to a lack of “trustworthiness and accuracy” (Yin 2004).

11 Multiple sources help alleviate lack of trust, increase viabil- ity, and frequently provide supplementary realms of thought and research that strengthen results. Design-Build Solicitation Content Analysis Sixty-six different projects were reviewed from 26 trans- portation agencies comprising 23 states, the District of Columbia, the U.S.DOT Eastern Federal Lands Highway Division, and one Canadian Province (Alberta), with a total contract value of more than $11.5 billion (see Figure 4). This sample included 59 RFPs and 15 requests for qualifications (RFQs), with 8 of the projects having both documents. The majority came from state DOTs, with a handful from special agencies or authorities that were set up for specific projects. The distribution of project type is displayed in Table 1. A matrix was developed from the content analysis output containing key quality concepts and practices. As the project literature review and survey progressed, further review was necessary for topics that had not been identified in the origi- nal content analysis. The information gathered was reduced to general categories that are detailed in chapter three of this report. The content analysis output was further combined with the results of the survey for this project and the literature that was reviewed to create the synthesis. Design-Build Policy Document Content Analysis In addition to the analysis of DB solicitation documents, the study also sought to identify state DOT DB policies and guide- lines that were currently available. Consequently, 17 sets of DB policies and guidelines from the 17 states shown in Fig- ure 5 were assembled and the process described for the DB so- licitation document content analysis was used to derive the quality content of each of those documents. General Nationwide Survey In addition to the content analysis, a survey was issued to state DOTs, other public transportation agencies, design-builders, and DB design and construction consultants (see Appendix C for details). A total of 63 complete and 13 partial responses were received. The survey respondents were from 47 states (see Figure 6). DOT responses from 27 of the 31 state DOTs that have performed DB are included. Additionally, three state DOTs that have not yet awarded a DB contract, but either are in the process of awarding their first contract or intend to implement DB in the future also responded. Re- sponses from five non-DOT transportation agencies (four transit agencies and one toll road authority) with DB experi- ence are also included as are the four responses received from FIGURE 4 Geographic distribution of design-build requests for proposals analyzed in this study. Major Project Types Minor Project Types Road 14 Mass Transit/Light Rail 4 Bridge 14 Rest Area 2 Road and Bridge 27 Tunnel 2 Toll Collection 1 Signage 1 Fiber Optic (ITS) 1 Total 55 Total 11 TABLE 1 DESIGN-BUILD REQUEST FOR PROPOSAL CONTENT ANALYSIS SAMPLE

12 FIGURE 5 Geographic distribution of design-build policy documents analyzed in this study. the engineering and construction industry. Survey respon- dents’ DB experience ranges from as early as 1988 to as recently as 2007, and from one completed project to more than 10. As can be seen, the survey also captured a wide range of states with DB experience. Design-Build Quality Perception Survey In public policy, perceptions are often of equal importance to facts. Legislative action is heavily influenced by perceptions and, as previously discussed, implementation of DB for public infrastructure projects has had to overcome the perceptions that DB project delivery would result in an inherently poor quality and possibly unsafe final product because the de- signer’s fiduciary loyalty has been moved to the builder’s team. One report on DB implementation classifies perceptions as “barriers to broad acceptance” (Byrd and Grant 1993). An interesting discussion of the issue of perceptions creating a barrier to implementing DB was published in 2005. Although it is specifically directed at architectural projects, its content applies directly to transportation. The article states that “archi- tects have groomed a cultural perception that builders can’t be trusted” and, as a result, participating in a DB project must be unethical. The author goes on to state: “That perception [that DB is unethical] subsequently contributed to many bidding and contracting laws that made design-build cumbersome or impossible in the U.S.” (Nicholson 2005). This perception is contradicted by the legislation that specifically authorizes the use of DB on all types of projects across the country. Never- theless, the perception is stubbornly persistent. Thus, this study has measured the perception of DB’s impact on project quality and compared it with the data obtained in the general survey. In this manner, the potential divisive influence of per- sistent anti-DB perceptions can be potentially identified. To accomplish this purpose, a short survey (see Appendix F for details) was distributed to TTB’s Design-Build Task Force FIGURE 6 Geographic distribution of general nationwide survey responses.

13 at its 2007 meeting in Washington, D.C. The task force is made up of both public agency and private industry professionals with an interest in the subject. Not all have DB experience. Many choose to join the task force for its value as a training and informational resource for DOT members who anticipate using DB in the future. Additionally, the meetings are open to the public and are well attended by nonmembers with similar in- terests. The meetings are lively and decidedly open to opinions from all sides of the DB issue. Thus, it is an excellent forum to capture the perceptional input that this study requires. Thirty- two surveys were issued and 23 responses were received, for a 72% response rate. The responses came from individuals work- ing for both private and public organizations in 17 states. Fig- ure 7 shows the distribution of those responses and highlights those that are from states that also returned general surveys. When one correlates these responses with the SEP-14 data, it is found that only three responses are from states with no DB transportation experience: Illinois, Iowa, and Oklahoma. The first series of questions sought to measure the potential threat to the DBB status quo by DB regarding the potential for public engineer job loss and DOT role changes. Half the DOT respondents believed that implementing DB would decrease the need for professional engineers in state service. Additionally, half the DOT respondents expected their role to change in a DB project. These results can be compared with a recent study of DB impact on the public workforce (Gransberg and Molenaar 2007), which found that 86% of the DOT respondents reported that their profes- sional workforce either remained the same or increased in size after implementing DB project delivery. The final two questions were designed to assess the percep- tion that the change in the designer’s role from working for the owner to working for the builder would degrade the ultimate quality of the constructed project. The survey asked the re- spondents to reveal their impression of the impact of DB proj- ect delivery on project quality. Interestingly, 78% indicated that DB quality was either better or equal to the quality of tra- ditionally delivered projects. Only one respondent indicated that the quality would be worse, and four had no opinion. Breaking out the responses by group, the public employees were evenly divided between “better,” “no change,” and “don’t know.” Eighty-five percent of private practitioners indicated that DB quality was better or equal. Again, there is a disparity between the two groups with the public employees showing no trend and the private practitioners indicating sub- stantial confidence in the delivery method. The final question asked who might be assigned the ma- jority of the responsibility for QA in a DB project. The results showed that nearly half the respondents believed that this essential task should be shared between the agency and its design-builder. The trend remained the same when the results were split out between the two groups. The perceptions survey showed that public agency engi- neers believe that their roles will change and are unsure of the impact on the quality of their most important deliverable: the constructed transportation project. Some see implementing DB as potentially reducing the need for public agency professional engineers. Given this discussion, it can be concluded that per- ceptions will probably remain a barrier to DB implementation FIGURE 7 Geographic distribution of design-build quality perception survey responses.

14 and that DOTs must be sensitive to this issue when developing their DB quality management policy and programs. COMMONLY USED PRACTICES Although developing commonly used practices was not the pri- mary purpose of this synthesis, a number have been identified and are organized in logical groups. The definition of a com- monly used practice for this synthesis is a method or procedure that was found in the literature and confirmed as applicable through survey responses. The DB RFPs whose content was analyzed are considered part of the application for purposes of identifying commonly used practices and the DB policy docu- ments reviewed were included as part of the literature.