National Academies Press: OpenBook

Information Technology for Efficient Project Delivery (2008)

Chapter: Chapter One - Introduction

« Previous: Summary
Page 4
Suggested Citation:"Chapter One - Introduction." National Academies of Sciences, Engineering, and Medicine. 2008. Information Technology for Efficient Project Delivery. Washington, DC: The National Academies Press. doi: 10.17226/14213.
×
Page 4
Page 5
Suggested Citation:"Chapter One - Introduction." National Academies of Sciences, Engineering, and Medicine. 2008. Information Technology for Efficient Project Delivery. Washington, DC: The National Academies Press. doi: 10.17226/14213.
×
Page 5
Page 6
Suggested Citation:"Chapter One - Introduction." National Academies of Sciences, Engineering, and Medicine. 2008. Information Technology for Efficient Project Delivery. Washington, DC: The National Academies Press. doi: 10.17226/14213.
×
Page 6
Page 7
Suggested Citation:"Chapter One - Introduction." National Academies of Sciences, Engineering, and Medicine. 2008. Information Technology for Efficient Project Delivery. Washington, DC: The National Academies Press. doi: 10.17226/14213.
×
Page 7
Page 8
Suggested Citation:"Chapter One - Introduction." National Academies of Sciences, Engineering, and Medicine. 2008. Information Technology for Efficient Project Delivery. Washington, DC: The National Academies Press. doi: 10.17226/14213.
×
Page 8

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.

5As the National Institute of Standards and Technology (NIST) quotation states in chapter one, there are currently potential estimated savings of billions of dollars that can be realized by increased efficiency (interoperability) of delivering design and construction to the capital facilities industry. The project delivery systems in the transportation sector are similar in structure to the vertical construction sector and typically involve similar (if not more) data collection and software systems, so that potential dollar savings can be significant to U.S. public infrastructure costs. The technology is currently available for U.S. transportation agencies to begin sharing in these efficiencies resulting from data interoperability. In most, if not every, agency situation, changes in work-flow processes, investments in new technology and human skill sets, and proper strategic planning will be required to realize financial savings. Most of the agencies studied and/or interviewed were aware of at least some very significant rewards for the “pain” of attempting change in their organizations. Most were very practical in their expectations and proud of their accomplish- ments (however incremental) on their way to these projected process efficiencies. The agency managers are quite aware of the infrastructure construction demands within their state boundaries and the competition for the financial capital to deliver the projects. This synthesis study is designed to assist transportation agencies in becoming more efficient by reporting its findings in the following areas: • Advanced processes of digital information flow through department of transportation (DOT) functional areas are described. • Through a national survey of DOT agencies and tele- phone and conference interviews, selected business practices are described and diagrammed by functional areas of the transportation construction project life cycle [planning, design, procurement, construction, and oper- ations and maintenance (O&M)]. • Digital data-flow “bottlenecks” (gaps) and possible solutions are identified. • Selected DOT business functions are diagrammed showing the flow of digital data in their respective efforts to deliver transportation projects. Software and hard- ware resources are identified. • Broad information on the current state of technology that allows software programs (digital data) to interface together (interoperability) is included. • As a result of a literature review of approximately 200 documents, basic interoperability problems and solu- tions are described. • Broad information on the current state of digital data standardization efforts that enable digital data interop- erability is reviewed. • As a result of the literature review, there is documentation of various efforts both within and outside of the trans- portation sector on how digital data can be created, uti- lized, and stored regardless of which software program, functional area, or project life cycle it passes through. • DOT functional area business practices that enable digi- tal data flow and therefore theoretically increased effi- ciency are presented. The most impressive (efficient) practices for project design and construction delivery are borrowed from either case studies or literature to visualize by means of a diagram of the most efficient model for digital data delivery through all of the transportation construction project life-cycle stages (integrated process model or IPM). • Human resource skills and knowledge that will be required to achieve the IPM are presented. • The technical and management skills that will be required of DOT staff for the possible requirements of re- engineering existing business work-flow practices and maintaining efficient digital data exchange in the ever- changing software and hardware technology advances are reported. • Extensions of research beyond the scope of this study are mentioned. • Finally, the study suggests additional areas of research revealed by the small “snap-shot” of information pro- vided by this synthesis. Transportation agencies are complex organizations. Al- though there are differing types of transportation agencies (federal, state, municipal, and specifically dedicated), this synthesis report is concerned with state-level agencies that are state-specific DOTs or turnpike authorities. The report is aimed at discovering the level of efficiency with which the DOTs perform digital transactions. Although this involves CHAPTER ONE INTRODUCTION

studying software applications and electronic data types, it is important at the offset to introduce, even to those already familiar with the processes and functions of these agencies, the scale, depth, and timelines involved with DOT agency information technology (IT) transactions. A sample list of essential and typical functions of a state DOT are as follows (Boyd et al. 2005): • Transportation planning and policy; • Research; • Grants management; • Transportation data, modeling, and simulation; • Geographic information systems and mapping; • Engineering; • Construction management; • Contracts administration; • Maintenance; • Inspection and repair; • Traffic control; • Incident management; • Intelligent transportation systems; • Enforcing compliance with federal regulations; • Enforcing compliance with state regulations; • Administering tax, fee, and levy programs and collecting funds; • Licensing vehicle operators and commercial carriers; • Supporting law enforcement by providing information on licenses and commercial carriers; 6 • Issuing permits for restricted vehicles and carriers; • Supporting military movement of goods; • Inspections and safety regulations; • Hazardous materials spills clean-up and oversight; • Administrative services; • Financial services; • IT services; • Legal; • Human resources; • Civil rights; • Internal audits; • Coordinating with local agencies; • Coordinating with other state agencies; and • Coordinating with the federal government. In addition to functional complexity, state DOTs are organi- zationally complex, as shown in a typical organization chart in Figure 1. Further complication with data sharing and communica- tions may result because the DOTs have established satellite offices throughout their state borders to manage construction and maintenance operations. These separate offices create gigabytes of information daily that are eventually reported and/or stored at headquarters. Because of the organizational complexities and variations that exist among state DOTs, the synthesis panel believed it was necessary to limit the focus of this synthesis study. FIGURE 1 Generic DOT organizational chart.

7The scope was therefore defined to target only those agency functions concerned with construction project design and delivery. As “owners” (stewards of taxpayer funds) of the state infrastructure, DOTs are tasked (typically) with the planning and design of construction infrastructure projects. Although the physical construction services are contractually awarded to private-industry contractors, the DOTs select the contract delivery methods (design-bid-build, design-build, etc.), inspect the construction work for quality assurance and qual- ity control (QA/QC), and define the aggregate project con- struction durations for the contracts. Once the construction contractors have completed their contractual portion of the work, the DOTs typically assume maintenance and opera- tions responsibility for the facility. For the purposes of this study, the DOT agency functions pertaining to construction project design and delivery have been subdivided into five principal areas of functionality. These functional areas do not represent the organizational structure of all DOTs, as some have these distinct function- alities absorbed into fewer (or additional, more specific) functional areas. In this report, our subdivisions match the project life-cycle stages shown in Figure 2, and represent the following functions: • Planning: The development of project design alterna- tives (feasibility) once a need has been identified. Also responsible for initial location and positioning data (location surveys) (D. Streett, New York State DOT, personal communication, May 31, 2007). • Design: The selection and detailed refinement of proj- ect alternatives regarding scope and design (D. Streett, New York State DOT, personal communication, May 31, 2007). • Procurement: Development and delivery of contract documents; selection of the prime contractor to build the project; and administration of construction, mainte- nance, and operations contracts and project manage- ment of the transportation projects. • Construction: Inspection of project materials and methods for compliance with minimum project quality specifications, and jobsite and administrative contract administration. • O&M: Stewardship of the constructed and opened facility. As advanced processes for the seamless sharing of infor- mation throughout DOT project delivery are identified, it is also necessary to define project delivery stages, also referred to as the project life cycle. The stages or phases are linear in process. That is, ideation and feasibility must precede design, and design must precede construction, etc. Contractual deliv- ery methods such as design-build procurement can alter the timing of each stage’s total completion (segmentation), but the overall process is linear. Figure 2 displays the stages involved in transportation project delivery. The phase diagram in Figure 2, with the exception of property acquisition, is typical for any construction facility, horizontal (transportation) or vertical. Best practice con- struction management requires the passing of data from one life-cycle stage to another. If this passing of data and infor- mation between the stages is not efficient or accomplished, it must either be re-created or re-entered into the dataflow. This typically occurs as software applications utilized to generate project data in one stage do not communicate with applica- tions and programs used in another stage or by other con- tractual stakeholders of the project. Contractual stakeholders are the parties contractually joined to accomplish the project life-cycle stages and typi- cally include an owner, designer, contractor, subcontractors, and vendor/suppliers as displayed in Figure 3. In the case of public-sector transportation projects, data must also be exchanged between federal, municipal, regulatory, and utility organizations. Therefore, the delivery of a transportation construction proj- ect requires a large amount of data communication (sharing) both within each stakeholder’s organization (internally), among the stakeholders’ organizations (externally), and across the project life-cycle stages. This study isolates some of these processes and procedures within owner DOTs. The effi- ciency with which an organization accomplishes this data sharing might be termed “advanced processes.” Consider finally the breadth or scale of the data involved, generated daily by the project stakeholders across the project life-cycle stages. Some of these internal data are revealed onFIGURE 2 Transportation facility life-cycle stages.

the work-flow process diagrams. These data must be shared and/or archived properly and timely for efficient project delivery. The ability to quickly recall specific data from the mass of data and information generated and stored during the life-cycle stages, without duplicating data entry, provides the basis of managerial decisions that can shorten the stages of the project life cycle (lessening inconvenience to the trav- eling public) and enhance economic development. This study, through literature review, survey questionnaire, and DOT case study, identifies the following in relation to transportation project design and construction: • Identification and reporting of agencies that have insti- tuted creative and efficient methods of productivity in the production of their functional area deliverables (advanced processes). • Identification of barriers and challenges involved in the attempts to efficiently process transportation design and construction data throughout the project life-cycle stages (and therefore the five defined functional areas). This involves business/work processes, software application interoperability, and strains on agency resources. • IPM, which is an idealized process map of the most effi- cient work processes, interoperable software applications, hardware, and agency resources for the delivery of trans- portation construction processes. Its basis is the literature review and the amalgamation of the advanced processes discovered in the various functional areas. • Recommendations for further research to extend this area of study. 8 Some definitions are required for comprehension of the following chapters specific to functional areas and our con- clusions. A brief introductory explanation on data file formats of software applications (computer programs) is appropriate before discussing data interoperability. There are three main types of computer programs: 1. Operating systems: these programs function at the lowest level (or machine level) and interpret inputs (keyboard, mouse usage, etc.) and outputs (to periph- erals such as printers and monitors) between the user and the computer hardware itself. 2. Interpreters and compilers: these programs convert high-level computer languages into machine language that the operating system can interpret. Computer pro- grams such as a video games, web browsers, spread- sheets, etc., are written in high-level “code” languages such as C, C++, BASIC, FORTRAN, Lisp, etc. Com- pilers read the program language (software code) and convert it to a binary format or language (utilizing switches of 0s and 1s). 3. Applications programs (or software applications): these are the computer programs that most of us are familiar with; they include all computer programs that are not operating systems or compilers. It is important to point out that software languages, once learned, can be interpreted by anyone who knows the language (in the same manner of our human written lan- guages). Therefore, if one knows the C++ language and hap- pens to view a program’s written language (also known as FIGURE 3 Contractual stakeholders and communication lines.

9“source code”), one would be able to decipher exactly how the program is designed to work and function. The user could even change or alter the source code to make the program perform additional or different functions (features). However, once the source code is compiled into binary format, the archi- tecture of how the program is designed with the program language becomes hidden. That is to say, it is impossible to learn how a software application is designed or how it func- tions by observing compiled binary code. These concepts are important to interoperability in the fol- lowing way: If end-users of computer programs could observe the source code, then they would have the ability to alter the programs to create customized features and uses and/or more importantly to interact with other programs more easily (i.e., to make two or more programs interoperable with each other). There are groups of programmers and users who believe it is unethical for computer software to be sold, licensed, or dis- tributed in binary format. Instead they distribute software in the source code format and allow the end-user to compile the pro- grams themselves. This allows the end-user to manipulate the program’s source code to cause the compiled program to serve their specific needs and requirements. These two main groups are referred to as the Free Software and Open Source Software movements. Their differences lie in how they value restrictive software licensing, copyright and patent laws (related to soft- ware production), and software development methodologies. Proprietary software developers typically distribute their software applications in binary format for competitive advan- tage. The programs are licensed to the end-user, typically per number of users and possibly for limited periods of time. Any changes in a program’s functionality must originate from the proprietor’s programmers (source code). This situation causes the end-user to be dependent on the software vendor in several ways, as follows: • If the end-user wants to customize a software applica- tion to match unique business processes, the end-user will be dependent on the vendor’s development schedule, the vendor’s willingness to make the changes, and the cost of development and licensing. • If the end-user stores data in the proprietor’s software application format, then long-term storage, access, and retrieval of the user’s data are dependent on access to the proprietor’s software application. Not only are there monetary licensing issues involved, but the user risks separation from the data if the vendor goes out of busi- ness, ceases to upgrade the software application when newer operating systems become necessary, etc. The end-user could be locked out of access to the data if stored in and dependent on a proprietary software pro- gram’s binary file format. Therefore, we have provided the following definitions here and in the glossary that appears at the end of this report. File format—a specific method of compiling information in a software application file. Open file format—a published specification for storing digital data, usually maintained by a non-proprietary standards organization, and free of legal restrictions on use. For example, an open format must be imple- mentable by both proprietary and free/open source software, using the typical licenses used by each. In contrast to open formats, proprietary formats are con- trolled and defined by private interests. Open formats are a subset of open standards. The primary goal of open formats is to guarantee long-term access to data without current or future uncertainty with regard to legal rights or technical specification. A common sec- ondary goal of open formats is to enable competition, instead of allowing a vendor’s control over a propri- etary format to inhibit use of competing products. Gov- ernments have increasingly shown an interest in open format issues (Wikipedia 2007). Open source software—a high-level software source code of software applications that is distributed before com- pilation into binary form. Proprietary file format—a program file compiled in a method specific to a proprietary software developer. Standard file format—an open file format that has been specified by a standards organization to which free, open source, and proprietary software developers vol- untarily adhere to. These definitions are useful for interpreting some of the tables in succeeding chapters and in the discussion in chapter eight.

Next: Chapter Two - Data Collection and Criteria for Identification of Advanced Processes »
Information Technology for Efficient Project Delivery Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB's National Cooperative Highway Research Program (NCHRP) Synthesis 385: Information Technology for Efficient Project Delivery explores "best practices" for the seamless sharing of information throughout all phases of the project delivery process.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!