Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Site documentation and as-built records of public sector construction project Dietrich, Brett Robert 1996

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata


831-ubc_1996-0211.pdf [ 5.86MB ]
JSON: 831-1.0050373.json
JSON-LD: 831-1.0050373-ld.json
RDF/XML (Pretty): 831-1.0050373-rdf.xml
RDF/JSON: 831-1.0050373-rdf.json
Turtle: 831-1.0050373-turtle.txt
N-Triples: 831-1.0050373-rdf-ntriples.txt
Original Record: 831-1.0050373-source.json
Full Text

Full Text

SITE DOCUMENTATION AND AS-BUILT RECORDS OF PUBLIC SECTOR CONSTRUCTION PROJECTS by BRETT ROBERT DffiTRICH B.E.Sc, The University of Western Ontario, 1994 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES Department of Civil Engineering We Accept this thesis as ccmfjowntpg' to the. required s^ntaaptk-'^  THE UNIVERSITY OF BRITISH COLUMBIA April, 1996 © Brett R. Dietrich, 1996 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. The University of British Columbia Vancouver, Canada Department DE-6 (2/88) Abstract This paper is a continuation of work to develop and test a prototype computer-based system to address the needs of a public owner - The British Columbia Ministry of Transportation and Highways. The Ministry continues to be interested in how they can exploit information technologies and the prototype system discussed here proceeds to address their concerns. After the research completed by Ralph English in the Spring of 1995 was concluded several outstanding issues remained. These included reporting features for certain routines, development of a quality management routine, a site trial, and modifications to current practices, such as improved record associations with pay items and activities. This prototype was built on top of a project management system called REPCON which has been developed over many years at the University of British Columbia. Implicit in this project is the ability to represent any project with multiple views. Depending on the required view, the system must be able to respond to the user to provide the appropriate data for a complete picture of the project. The objectives for this thesis include: modifications to the Pay Item and Activity routines; thorough report generation in the Daily Site routine; select-sort and reporting in the Records routine; a description of future work required to generate a Quality Management view of a project; and, an outline concerning a Change Order Management routine. This thesis increment represents the latest endeavor to address the Ministry's construction management needs as a public owner, and thus help demonstrate to the Ministry some of the opportunities and benefits information technologies offer. The advances achieved through this thesis more acutely respond to the immediate realities the Ministry has. Through the improved Daily Site feature staff are now able to produce a wide range of reports to reduce the requirement to search countless forms for relevant data. The as-built views that can now be produced exemplify a construct from which lessons can be learned and innovations can be applied to subsequent projects. In essence the Ministry has captured data to use on future projects. Table of Contents Abstract ii Table of Contents iv List of Figures vi Acknowledgment viiX Chapter 1: Introduction 1 1.1 Motivation and Opportunity 1 1.1.1 Technical Developments: Hardware and Software 1 1.1.2 Project Monitoring 2 1.2 Objectives of this Work 5 1.3 Methodology 5 1.4 The British Columbia Ministry of Transportation and Highways 6 1.4.1 The Bamet Highway 8 1.4.2 Field Staff Organization 10 Chapter 2: Background Work 12 2.1 Previous Work and Premises by Ralph English 12 2.2 Findings from Literature 13 2.2.1 Change Order Management 14 2.2.2 Information Management 16 2.2.3 Field Data Acquisition 19 2.3 Finding from the Field 20 2.3.1 Field Test One Discoveries 20 2.3.2 Field Test Two Discoveries 22 Schedule Issues 36 Pay Items Issues 38 Quality Management Issues 38 Daily Site Report Issues 39 Site Records 43 2.4 Observances about Original System Design and Field Realities 43 2.4.1 Scheduling and Daily Site Tracking 43 2.4.2 Pay Items 45 2.4.3 Quality Management 46 2.4.4 Records Management 47 Chapter 3: System Design and Modification 49 3.1 Philosophy of Multiple Views 49 3.1.1 Definition of a View 4 49 3.1.2 General Philosophy 50 iv 3.1.3 Advantages and Disadvantages of Each Distinct View 52 Activity View 52 Pay Item View 52 Daily Site View 53 Records View 53 Quality View 54 Change Order View 54 3.1.4 Overlap of Views 55 3.2 Design and Modification of the Views 55 3.2.1 Activity View Modification 56 3.2.2 Pay Item View Modification 58 3.2.3 Daily Site View Modification 67 3.2.4 Records View Modification 75 3.2.5 Qualify View Design 85 3.2.6 Change Order View Design 88 Field Order (FO) 90 Extra Work Order (EWO) 91 Contemplated Change Order (CCO) 91 Change Order (CO) 92 Subcontract Change Order (SCO) 92 Chapter 4: Implementation and Field Experience 101 4.1 Site Trial Data Results 101 4.2 Pay Item View 103 4.3 Daily Site View 108 4.4 Records View 118 4.5 Quality View 121 4.6 Change Order View 121 Chapter 5: Technology and the Future 123 5.1 The Digital Camera 123 5.2 Exporting and Importing Data 124 5.3 Programming Wants 125 Chapter 6: Conclusions and Recommendations 128 Bibliography 131 v List of Figures 1.1 Example of The Ministry of Transportation and Highways Pay Item Schedule (Unit Price Contract) 1.2 Diagram of Project 9052 Location 1.3 Ministry Site Supervisory Team 2.1 Example of Daily Site Form 2.2 Example of Memoranda 2.3 Example of Proj ect Diary 2.4 Example of Internal Pay Item Report 2.5 Example of Pay Item Estimate 2.6 Example of Quality Testing List 2.7 Example of Quality Test Result 2.8 Example of Extra Work Request 2.9 Example of Accepted Ministry Supplemental Agreement 2.10 Example of Minutes from Weekly Site Meeting 2.11 Contractor's 3-Month Schedule 2.12 An Example of Filled Out Daily Site Form 2.13 An Example of Filled Out Daily Site Form 3.1 Project Views 3.2 Activity and Record Associations Through Activity Routine 3.3 Pay Item Progress Measurements, With Activity Breakdown 3.4 Pay Item Progress Measurements, No Activity Breakdown 61 3.5 Pay Item Progress Measurement Reporting 64 3.6 Pay Item and Record Association Through Pay Item Routine 66 3.7 Standard Reports 70 3.8 The Report Generator 74 3.9 Record Select Profiles 79 3.10 Record Sort Profiles 82 4.1 The Test Project 3-Month Schedule from REPCON 102 4.2 A Page from REPCON's Pay Item Progress Report for November, 1995 105 4.3 A Page from The Ministry's Pay Item Progress Report for November, 1995 106 4.4 A Page from REPCON's Pay Item Progress Report for October and 107 November, 1995 4.5 Daily Site Report Generated from REPCON 109 4.6 Corresponding Ministry Daily Site Report 110 4.7 A Work Environment Report 112 4.8 A Work Force Report 113 4.9 A Deliveries Report 114 4.10 An Equipment/Rentals Report 115 4.11 A Miscellaneous Notes Report 116 4.12 An Example of the Report Generator Wrap Around Feature 117 4.13 An Example of a Records Report 119 4.14 An Example of a Records Report 120 vii An Example of a Digital Camera Image 124 viii Acknowledgment The author asseverates his genuine gratitude to the following people for their help and support during the completion of this thesis. Foremost, to Dr. Alan D. Russell for his great insight and inspiration during my education at The University of British Columbia. The knowledge and self-confidence that I acquired are invaluable. To The Ministry of Transportation and Highways of British Columbia for their financial support of this research. To Mr. Singh Jassal and the entire Project Site Staff especially Dana, Dave M . and Barb for their valued assistance to me during my site visits. The time they took to accommodate me and answer all my questions is greatly appreciated. I indeed have a great respect for the work they continue to do. To Luong Pham and William Wong for their great programming skills and quick response to my requests. And finally to Marianne for all her moral support and encouragement during this phase of my life. ix Chapter 1: Introduction 1.1 Motivation and Opportunities After the research completed by Ralph English in the Spring of 1995 was concluded several outstanding issues remained. These included reporting features for certain routines, development of a quality management routine, a site trial, and modifications to current practices, such as improved record associations with pay items and activities in the system, to mention a few. As information technology advances, the need for a comprehensive, computer-based representation of construction projects becomes increasingly important. Public and private owners alike need such a tool to stitch their projects together. The resulting design must facilitate this requirement: multiple views of one project with one set of associated data. The sometimes arduous tasks of on-site reporting and decision making, claims support, and design feedback will all greatly be enriched and improved. 1.1.1 Technical Developments: Hardware and Software With the increase of information technologies, the public sector, like the private sector, should be encouraged to exploit them where possible. The potential now exists to monitor progress and resolve problems in real time. This presents a real benefit to all 1 concerned as significant cost and time savings can be realized by expediting project control. 1.1.2 Project Monitoring The British Columbia Ministry of Highways and Transportation (hereinafter referred to as the Ministry), a public owner, has the need for a construction documentation system because of their greater accountability to the public as compared to a private sector company. The paramount role of the Ministry is the assurance of quality on a project. Thus, the Ministry is obligated to document selected aspects of construction history in greater detail than what would be generally required by the private sector. There is a need for an effective technique to functionally manage the many views of a project. Internal reporting and claims analysis rely on the vast assembly of project data. Therefore, the ability to view this data and extract all comparable particulars is extremely importation to the Ministry. This situation is compounded by today's increased risks associated with greater costs to complete projects: again the requisite for a better documentation system. Additionally, the Ministry has financial tracking and tracking needs that tend to be different from the private sector. The Ministry's direct costs are expressed in terms of contract pay items (unit price contracts), a project view that is often missing in commonly available project management packages. Such software tends to be restricted to an activity-based view of site monitoring. This view limits the usefulness of the software for both public and private sector project management needs. 2 The work undertaken by the Ministry, by its nature, is relatively consistent and repetitive in nature; thus, the benefits of better records and data management are considerable. If the lessons learned from one project can be pragmatically applied to subsequent projects a great measure of knowledge can be exploited. Again, a better system with distinct views and record organization will aid the Ministry in claims support. Cost savings could be expected through the reduced effort required to compile data for specific reporting functions. The Ministry has traditionally administered its construction projects in unit price contract format. This arrangement results in the keeping of many unique records involved in the tracking of costs incurred as contract pay items, as well as many records and data being collected to document progress on the contractor's activities and schedule. See Figure 1.1 for an example of a contract pay item schedule. The consequences of this vast amount of discrete information is a picture of the project that can be viewed from many angles such as activities or pay items, while associations between individual data exist, they are difficult to represent properly. Any computer-based system must address this issue to provide for discrete views of the project while still allowing for associations to be preserved. 3 lfiTEM#S j ••. LIMIT OF MEASURE APPROX QUANTITY UNIT PRICF. EXTENDED AMOUNT' : 2 3.2 Type "D" excavate, load, haul, and dispose m3 112,700 2 3.3 Type "A" excavace, load, haul and dispose m3 250 2 3.4 Allowance f o r Payments Under S p e c i a l Provisions Clauses 2.3(c f o r Type C Excav. P.S . 1 $5,000.00 $5,000.00 2 E x i s t i n g pavement Removal, and Recycling (SP 2.4) 2 4.1 Remove and dispose m2 1,450 2 4.2 Remove by m i l l i n g , f u l l depth ra2 14,200 2 5 Increased Compaction (SP 2.5) ra2 12,600 2 6 Granular M a t e r i a l s , supply, haul and place (SP 2.6) 2 6.1 25mm well graded base m3 11,300 2 6.2 50mm we l l graded base m3 10,100 • 2 6.3 Selected Granular Subbase m3 29,600 2 7 Imported Embankment M a t e r i a l (SP 2.7)Supply, Haul Place and Compact m3 66,800 2 8 Drainage Blankets, supply, haul, place and compact (SP 2.8) m3 2,600 2 9 Fencing and Gates, Supply and Place (SP 2.10) 2 9.1 Fencing, (13-SP203) c/w 25x50 Battens m 280 Figure 1.1: Example of The Ministry of Transportation and Highways Pay Item Schedule (Unit Price Contract) 4 1.2 Objectives of this Work A key objective of the prototype system described herein is that it responds to the realities of monitoring public sector projects. The ability to combine project information collected from varying perspectives is an essential requirement of the Ministry. This thesis builds on the work performed by English (1995) which was directed at developing a working protype that reflects the needs of the Ministry. This prototype was built on top of a project management system called REPCON which has been developed over many years at the University of British Columbia. Implicit in this project is the ability to represent any project with multiple views. Depending on the required view, the system must be able to respond to the user to provide the appropriate data for a complete picture of the project. The objectives for this thesis include: modifications to the Pay Item and Activity routines; thorough report generation in the Daily Site routine; select-sort and reporting in the Records routine; a description of future work required to generate a Quality Management view of a project; and, an outline concerning a Change Order Management routine. Complete definitions of the former terms are available in English's work where they were developed. 1.3 Methodology This thesis was designed as a continuation of the work initiated by Ralph English, 1995, for the Ministry of Transportation and Highways of British Columbia. The focus of 5 his thesis was to further refine, enhance and enlarge the construction management features of REPCON to satisfy and accommodate the Public Owner. Work began with a search through the available literature to develop an appreciation of current views on construction management documentation and pertinent aspects of project monitoring. Subsequent effort was directed at weeding out programming errors in certain features of the prototype system built on top of REPCON in order to prepare for a site trial of the software in the fall of 1995. Prior to the November site trial there was a short orientation period at the construction project selected in order to develop an understanding of practices of the Ministry. Results from this period and the site trial were used as a basis to add refinements and enhancements to REPCON in the latter part of 1995 and the early part of 1996. Once these were completed, data collected from the project test was entered and analyzed to assess the capabilities of the prototype system.. Finally, conclusions from all of the forgoing were drawn. 1.4 The British Columbia Ministry of Transportation and Highways The Ministry's South Coast Regional Office in Burnaby, B.C. is responsible for the administration of most highway work in the Vancouver area, including major highway construction projects. Many such projects are monitored by in-house site supervision teams (others by similar teams contracted from the consulting industry), which are typically assigned to an individual project for its duration. These teams perform the 6 project documentation on behalf of the owner, and also serve as the owner's on-site liaison with the prime contractor. Under the terms of the standard Ministry construction contract, the prime contractor is assigned the responsibility for construction of all project works in accordance with the required specifications for materials and performance, while the Ministry assumes responsibility for assuring that these requirements are met and that value is obtained on the expenditure of public finances. Inherent in this structure is the basic philosophy that the contractor be given sufficient flexibility to exploit the advantages of competitiveness in the private market, while limiting the imposition of constraints to those required to ensure quality, timeliness, and conformity with regulatory requirements (e.g. environmental). The contractor then is free to adopt any accepted construction strategy which meets the stated constraints; his as-planned schedule is submitted prior to construction start-up for review and approval by the Ministry (English, 1995). As with most Ministry capital projects, the construction contract for Project 9052 (the test project) was tailored to have the majority of work completed under the responsibility of a prime contractor in direct contract with the Provincial Government of British Columbia. The prime contractor in turn may subcontract any of the component works to other pre-approved vendors. The contract is structured in a strictly unit price format for all planned work. This implies that a pay item exists for all measurable work in the project, generally representative of the material quantities used for various applications. From a Ministry perspective, labour input is for the most part considered incidental to the provision of the physical works, as are such ancillary tasks as traffic 7 control, quality control testing, and contractor administration. This simplifies the Ministry's task of determining the progress payment due by having the single unit price for each contract pay item represent the full cost for supply, installation and administration of the work by the contractor (English 1995). 1.4.1 The Barnet Highway Project In order to do further testing on REPCON, a project and access to records and project staff was required. Since the contract English used in his work was nearing completion, an alternative contract was selected for analysis. The second phase of the Barnet/Hasting People Moving Project, Project 9052, proved to be a suitable candidate. This project is described as approximately 4.4 km of four lane arterial reconstruction along the Barnet Highway from the Petro Canada Station on the North side of Burnaby Mountain to St. Johns St. in Port Moody, British Columbia. Significant project features include 0.855 km of split grade, 8 Reco retaining walls (Wall 3 being the largest along the split grade), a concrete pedestrian overpass over the westbound lanes at Wall 3, and 2 lock block walls. See Figure 1.2 for a project location diagram. 8 Figure 1.2: Diagram of Project 9052 Location 9 1.4.2 Field Staff Organization The Ministry's site representative's role is limited to that of the documentation of progress against the contractor's approved as-planned schedule, assurance of quality, and contract administration from an owner's perspective. The Ministry's site supervisory team that was assigned responsibility to Project 8690 (English's study project) is also responsible for the adjacent project 9052 (this thesis study project). This team includes a Project Supervisor, a senior assistant, three office personnel, and six field personnel. Of the site office staff, two are dedicated to computer interpretation of downloaded electronic field survey data, calculation of the resultant progress quantities, and drawing production. Other than the single survey supervisor, field staff generally rotate duties between daily data collection, testing and survey support in an effort to encourage an overall understanding of the project and to improve interest (English, 1995). Figure 1.3 shows the supervisory team. Office Manager Project Supervisor Senior Assistant 1 daily diaries • daily site reporting • progress reporting CAD/Computer Technician CAD/Computer Assistant survey data interpretation 1 progress quantity calculations > drawing production Site Inspectors (4) • daily site reporting • quality management testing • photographs, videos Survey Supervisor Survey Assistant • progress measurements • layout • survey quality assurance Figure 1.3: Ministry Site Supervisory Team (English, 1995) 10 It is this site staff that is responsible for the overall monitoring of the project. Since they are the ones most closely associated with the undertaking, they become the ones responsible for stitching all the data and various views of the project back into one complete view, which is more a mentally based one as opposed to a computer-based one. This compilation of information currently is accomplished by the accrued knowledge of the project that the staff process. Anyone not involved in the actual project would have great difficulty in aggregating data into useful views with no precognition of the project details. 11 Chapter 2: Background Work 2.1 Previous Work and Premises by Ralph English The following relevant excerpt is taken from English's 1995 thesis conclusions: The prototype system developed as part of this thesis successfully incorporates the following additional features into the existing REPCON platform: 1. Contract Pay Items - breakdown structure definition; cost and quantity; summary reporting. 2. Pay Item and Activity Mapping - associations between pay items and activities; pay item quantity breakdown by activity and location; costs to owner; summary reporting. 3. Progress Measurement - tracking of pay item progress; determination of progress payments; summary reporting. 4. Quality Management - creation of standard and project-specific test listings; test association with pay items; summary reporting. 5. Records Management - listings of available site records; associations with activities, pay items, project locations, problems, and other records; searching and sorting on specified parameters; scanned viewing. 6. Daily Site reporting - resource tracking by activity; pay item status; revised site data reporting categories. 12 English also recommended certain aspects for future work. Since his work was performed on only a small subset of the data collected on site of an actual Ministry project, he suggested that a more rigorous field test be conducted over an extended period. This additional field test would provide for further refinements to the features of REPCON. English also suggested additional system features that were not accommodated in the prototype and may warrant inclusion in a future version of the system. He indicated that routines have been designed as part of [his] thesis for the eventual accommodation of supplementary pay item status information, quality management test result, change order details, and record search results reporting. Another recommendation he made was to incorporate available pay item, testing, and resource information in the daily site report forms generated by the system, which provided completed fields for expected activities only. His view was that users of the prototype would benefit from a greater range of available reporting functions, which necessitates providing flexibility in report formatting such that data compilations can be created for the analysis and support of unique claims, as well as for further improving the content of standard project reports. 2.2 Findings from the Literature An extensive literature search revealed findings related to change order management, information management and data acquisition, three topics of interest to the 13 further development of the prototype system, presented in the discussion that follows. Other peripheral issues identified will be 2.2.1 Change Order Management The ever increasing cost of current construction projects is requiring more efficient project management with less inefficency for situations involving change orders. However, an actual standard process for proper change order management does not exist. Like many elements in construction management, change order management has developed with each project manager relying on his/her own process, and hence, it becomes difficult to realize a conceptual view of a general change order methodology. Moreover, the literature itself does not tend to document these processes either but tends to focus on more general issues rather than the ones of a design nature. For example, Abudayyeh (1994) suggests six recommendations for management of change orders in his paper dealing with partnering and quality construction management. The goal of the parties [in a construction project] is to improve the processing and management of change orders (Abudayyeh, 1994). His six recommendations follow. 1. Use negotiated-price orders as much as possible. 2. Anticipate changes and discuss them as early as possible. 3. Contractor screens subcontractors' estimates for change orders. 4. Take actions (sign/not sign) on change orders quickly. 5. Get daily reconciliation on the amount of time and material used in performing the extra work. 14 6. Contractor will provide detailed breakdown of costs involved in a proposed change order. Construction projects are bound to encounter change orders. If this is recognized by owners and contractors alike and the necessary planning is clear at the inception of the project much unproductive time and effort can be avoided (Ehrenreich-Hansen, 1994). With 30 years of project management experience in many countries and with projects ranging from $10 000 to $13 billion, Ehrenreich-Hansen presents his findings in his paper. A change order optimization process is described involving the project object and scope of work as well as plans for time, risk, costs, management and controls. The author underlies these issues with the premise that change order management should start early in a project. A procedure of identifying and analyzing the uncertainty associated with a potential change order is presented in a paper by Knoke and Spittler (1991). It is known as direct range estimating for change orders and involves the risks associated with the change order. This work is designed for the financial management of change orders rather than the overall method of documenting and tracking of such changes. The best way to control change is to manage it using a change management system which permits the client to make modifications in a structured, timely manner (Cohen, 1992). Cohen has developed a system known as The Estimate Deviation Notice Change 15 System (EDN). This system was tested on a research facility being built in the United States and a series of recommendations result from this work. Cohen identifies several key attributes to include in a documentation form: project title, project number, change type, description, reasons for change, authority, design schedule effect, estimate of construction costs, estimate of design workhours, estimate of total design costs, and list of design documents in change package. A computerized list of EDN's is tracked through LOTUS 1-2-3 or D-BASE where such particulars as clients, dates and approval are sorted and updated. 2.2.2 Information Management Many papers confirm that throughout the life of a project vast amounts of data are accumulated. The management of this information becomes of paramount importance as post-project claims support and litigation increase, Of the varied documentation systems under development, Liu, Stumpf and Kim (1994) are advancing a system called MULTROL which is a multimedia project control and documentation system. MULTROL has two major functions, information storage and retrieval. Diverse information formats of text, images, video and sound can be stored and attached to the related project activities (Liu et al, 1994). Another system under development by Abudayyeh (1995) is a pictorial information management system (PIMS). This system involves digitizing video scenes from a job site 16 and storing them in a computer. Microsoft Access is used as the relational database management system for the implementation of PLMS. Construction industry information used effectively represents an essential component in the decision making process (Riley and Pickering, 1994), which is of great benefit to quality assurance. Riley and Pickering report that "[quality assurance] is principally concerned with performing tasks correctly the first time. Whilst it embodies a number of organizational issues within a company, for a QA system to operate effectively, information must flow along well-defined channels and records of its movement must be kept so that the QA system can be audited. Q A therefore, represents a way of formally linking a system for the management of resources (PM) with a system that manages the flow of information. By integrating QA with PM tools on a computer-based system, it will be possible to significantly improve the project mangers' chances of making the correct decision, the first time." The authors describe their first steps towards producing a system to link project management to quality assurance using Microcosm, a hypermedia-based computer application which uses dynamic data exchange through the Windows environment to organize data among various software packages. Daily log reports are another example of essential documentation records that must be considered for computerized organization as accurate information is essential for project feedback. Liu, Stumpf, Chin, Ganeshan and Hicks (1995) present in their paper a construction daily log management system using multimedia technology call M-LOG. M -17 LOG allows construction site personnel to enter, store and retrieve construction daily log reports in multimedia formats including text, images, sound and video (Liu et al, 1995). Their system runs on a portable PC-486 notepad computer with pen-based data input capability and a digital camera is attached through a standard serial connection. The authors believe that better documentation minimizes potential problems and encourages lessons-learned and innovation. A conceptual data model and a prototype system named CADD-based Construction Information Management System (CADCIMS) has been developed, by Chin, Liang, Lui, Stumpf, Ganeshan and Hicks ( 1995), based on multimedia project control and documentation system (MULTROL) and CADD-based information retrieval system (CADCON). The purpose of the CADCIMS model is to build an information structure to capture, store, retrieve, manage the as-built information including multimedia data types, and to provide facility [operation and management] with accurate construction information (Chin et al, 1995). CADCIMS relies extensively on other software systems such as a schedule generator and a documentation system to properly perform; it is not a stand-alone system. Accurate and complete as-built information provides benefits to designers, contractors, and owners. Designers can obtain valuable feedback on how effective their design was. Contractors can benefit from well-documented past experience. Owners can accurately document and trace construction progress (Liu et al, 1994). However, Liu, Stumpf, Kim and Zbinden (1994) identify a real problem in their paper on capturing as-built project information for facility management. Currently there is a lack of coordinated 18 methods and structures for collection, storage and retrieval of as-built project information which may benefit not only facility operators/maintainers but also designers and contractors to optimize life cycle cost and value (Liu et al, 1994). Addressing this lack of methods and structure is a major objective of this thesis by stitching the entire job back together once again after the major views of the project are established. The motivation for doing this varies somewhat from those of Lui et al (1994). 2.2.3 Field Data Acquisition One of the most important aspects of developing as-built project records is collecting the appropriate field data. Construction site availability of advanced portable computing, multimedia and wireless communications allow, even encourages, fundamental changes in many job-site process (Songer and Rojas, 1995). Songer and Rojas are developing a field inspection reporting system for the construction industry (FIRS). Their system utilizes several input devices. The basic system consists of a portable computer with a sound card for voice recording. The system can grow with a voice recognition capable computer, a digital camera and/or digital video input. The pen computer has become a powerful field supervisor's tool for automated construction companies (Coble, 1995). Expanding pen computing applications is the focus of Coble's paper. The pen computer is light-weight and does not require extensive care in transport. The addition of photo-optics allow it to become a memory bank of job activities and daily updates. Fax capabilities are available which allow for the direct link 19 from field to office and lastly touch screens for field applications are available to greatly simplify data acquisition. Many situations in construction require accurate documentation of site conditions including construction progress, quality control, quality safety, and changes (Liu, 1995). To accurately document events and conditions Liu presents, in his paper, the development of a data communication device named Digital Hard Hat. This apparatus is mounted with devices for communicating/capturing construction site conditions in multimedia formats of text, images, video and sound through the means of an electronic notepad, microphone, head sets, video camera, and a heads-up display to transmit, receive and store the data. Field personnel can confer in real-time two-way communications with local and remote experts through a computer network. 2.3 Findings from the Field The field testing for this thesis was divided into two distinct field trials. The first two week trial was designed for familiarization with Ministry procedures, and to establish the project schedule. The second field test was to be longer, approximately one month, and it would be used to gather all the project data for the month of November in order to critique the usefulness of the modified REPCON features. 2.3.1 Field Test One Discoveries 20 This preliminary field test was intended to last for two weeks in October of 1995, in order to get an flavour of Ministry procedures concerning daily documentation. The initial aim was to collect two weeks worth of data and enter it into REPCON's Daily Site feature and consequently critique the experience for the subsequent field test. The plan was to establish the project's schedule for the two week period and systematically document the flow of information in REPCON through the Ministry's site office. Problems began with the realization that the contractor had not been supplying Ministry personnel with current schedule updates. In fact, despite a contractual obilgation to do so, no current schedule had been submitted. This problem later would develop quite seriously and result in a significant observations about the system's limitations in terms of requiring a schedule. Since a schedule was not forthcoming, it was decided that a two week schedule based on documentation that had already been collected would be produced. After a laborious effort to glean a schedule from daily site reports, it became evident that this was no easy task. Another problem: The Ministry keeps extensive records on everything occurring during a project; however, it is in a fashion that does not easily facilitate common data retrieval. This observation helps to reinforce the validity of the thesis objectives. This project was about half way through its life and already The Ministry has collected over two filing cabinets full of documentation. Extensive yes, but the system lacked common associations and links from one set of data to the next. It was decided that the effort to deduce a schedule was futile as an exact project would have been created to monitor against, thereby disallowing for the possibility of'problems' to arise. 21 The as-designed schedule would also have been the as-built schedule and anything learned from the daily documentation procedure would have been lost. The next task ahead was to determine typical Ministry procedures. As an outsider to the Ministry it was necessary to become established at the site office and gather the necessary information. This approach was successful with the help of site staff. From scrutiny of the extensive on-site records the author was able to gain an adequate feel for how "things" were done which allowed a better evaluation of the strengths and weaknesses plus reasons behind current procedures. 2.3.2 Field Test Two Discoveries This second field test was performed in November and the first week of December, 1995. However, several trips to the site office subsequent to this were necessary to complete the data acquisition for this thesis. This was the field test by which the bulk of the site data was collected in order to more extensively test the enhancements to the as-built view supported by REPGON. To better understand the expansive amount of data collected consider the following list of data forms. Some comments on how well these forms are filled out are offered as well. • Daily Site Forms - a standardized form filled out daily that includes a.m. and p.m. temperature and weather; manpower/equipment in use/activity reporting divided into pay items and station to station units; extra work orders; hauling; visitors on site; quality assurance; and authorization signature. See Figure 2.1 22 for an example of a daily site form. Note that the pay item list is not used and the bottom of the form is blank: this is typical. The activites section represents what is actually happening, not what was on the contractor's schedule. Memoranda - various memoranda to and from the Site Office regarding such circumstances as quality assurance and correspondence between parties. See Figure 2.2 for an example of memoranda. Survey and Project Diaries - documentation of the daily work completed by the surveyors which include diagrams and station to station quantities of pay items; supplemental information contained in these diaries, such as relevant observations and discussions, tend to augment other records. See Figure 2.3 for an example of a project diary. Progress Estimate of Pay Items (internal)- monthly reports of total quantities and dollar amounts to date, as well as monthly amounts; progress measurements provide a further indication of status as well as a means of determining contractor progress payments; most measurements are documented in the form of quantity surveys performed by Ministry staff while others may be obtained by weight scale, visual estimate, field count, or contractor invoice. See Figure 2.4 for an example of an internal pay item report. Progress Estimates of Pay Items (from contractors) - daily and monthly quantities from the contractors used as a backup against which to reconcile progress. See Figure 2.5 for an example of contractor Pay Item estimate. 23 Quality Assurance Methods and Responsibilities - complete listing of all quality testing to be completed on the project. See Figure 2.6 for an example quality testing list. The Work Item heading represents the Ministry Pay Items Quality Assurance Reports and Results- a wide range of all quality testing being completed; arriving in the Site office daily but lagging in time as to when they were conducted; formal results from quality assurance and control are kept in the appropriate format based on the tests performed; ideally all testing should be in terms of pay items only. See Figure 2.7 for an example of a quality test result. Work Order/Supplemental Agreement Form - used for extra work and is a supplement to the standard list of pay items. See Figure 2.8 for an example of an extra work request from a contractor (not yet approved - only the request); and Figure 2.9 for an accepted Ministry Supplemental Agreement for the extra work. This supplemental agreement shows up at the end of the pay item structure as a individual number. Minutes from Weekly Site Meetings. See Figure 2.10 for an example of minutes. Photographs and Videos - field personnel take numerous photographs of work in progress and other notable site occurrences; include such information as site activities, resources, active location, pay items used and site conditions; videos are not as common but are encouraged for unique incidents. 24 In order to properly address the records keeping and documentation of a project it is important to understand what transpires on a typical day at the site. Normally, the daily routine at the site office would include the following regular procedures. • fill out the daily site form • download all the previous day's survey information • receive and file all incoming correspondence and quality assurance • document pay item amounts (sometimes done on a monthly basis) These daily procedures are augmented by the monthly payroll, the monthly pay item report sent to the Regional Office, the weekly site meetings with all concerned parties, and the addressing of atypical concerns. 25 P R O J E C T : BARNET HWY. R E P O R T N O . DATE: C O N T R A C T NO: 09052 C O N T R A C T O R : BA DLACKTDP I N S P E C T O R : Tenpi AM_-o4C Weo'then AM_2_. >»_.•_: M A N P O W E R / E Q U I P M E N T IN U S E / A C T I V I T Y (nulir s|irClul nut * vf «qm()(-i*nt nov id on/off Illr. «iid ony specialized equipntnt In usr) P A Y itru S T A . T O S T A . A C T I V I T I E S E Q U I P / M N P W R O O - M O D f ' > / ' • ' • V . A C ' ' I ? I ' "£0 ' - J - ... ( w o <iftX"Ce T O O A V ") ~~ H ^ U L / i O G - — ^ A-( f | >P C O M y ' O C * ; A ~ l " C'C, *"«" r ; V -= . - , - . 0 0 - 9 f t . / o K 3 V 0 0 - in ur t V r / ^ A L a o r . 2 . C C A r v : . S rtiTTw^'JAUOAtif^o-M / < L S T A T / 0 > J S &• J ? A O / ^ A Z T ' O / ^ > A J _ T / S " / " A f ; f - J o c ( ; / ; v g f , ) R O - f V i . 2 . 0 S P e e A o i A J C « n 0 0 M /<. <y„s f i C - U i..v..t A ™ •• - , c R I T M O V ' O C V r r 0 r * r i 5 i F C O M C o o c c f T c C ' . A : - ; | - J . J P ' . A C r W A < L < V , • 1 7 . 2 0 - 8 7 . 5 0 A S S ' S T / K J C J . >„J P O C I ^ O C ' C R i r M o \ / A £. i O A t d . T , ffXiS'OG C A T C / V / i f t S / O ^ . C C D U r ^ d - A t C O f , C A ^ V . J A ^ R f i * c o - / o ,.„ = 3 S ' C O - 9 f l 4 I C ? / . , A ^ > < " ^ E w t 7 A 2 . i ' m i V O r 1 W r S u J | | R - , . - , . ; ( . > : 0 : n /••r\c.i_-/!•:;,: p. -y . c o - ? a.i / 0 i - l i e / C o ^ r s ^ / u 6 H A U L S / K : > I O « , i G i f i 2.S-<;KJ'<-->I,'--1-r X*->STAU.**JC- p u t t r A n ^ T - O r r t *; c c o s ^ r . r-. / \<v- . - , - / i .>6 t p , . C O - 7 R V 0 0 C T EXTRA WORK HAUL run No._ I.ncn linn l.quipneni Hrs Manpower Hrs Material Cut S/S Fill S /S Vo l /LC VISITORS UN SITE DUALITY ASSURANCE P.S. SIGNATURE "- '^P. SIGNATURf 1. Figure 2.1: Example of Daily Site Form Province of British Columbia Ministry of Transportation and Highways M E M O R A N D U M Singh Jassal Project Supervisor South Coast Region September 1, 1995 Geotechnical and Materials Engineering Services 3402 Willingdon Avenue Burnaby, B . C . V 5 G 3G9 Tel: (604) 660-5935 Fax: (604) 660-9559 File: 09052 Re: P ro jec t N o . 09052, Wa l l s A & B, L o c k B l o c k Wal l s H a r d e n e d C o n c r e t e A i r Vo id A n a l y s i s The letter from Robert Gray, P.Eng., Senior Materials Engineer with Terra Engineering Ltd. (attached) regarding the air void analysis by Levelton Associates has been reviewed by Geotechnical and Materials Engineering. The following comments are offered. While the air content (10.2%) is above the range specified in the Contract, I am in agreement with the thrust of the argument that the potential freeze-thaw and deicing salt resistance of the concrete in this particular lock block is more than adequate. I am also in agreement with Dr. Gray that the compressive strength could be compromised by the high air content. However, Schmidt Hammer readings (attached) would indicate that the 28 day compressive strengths of this group of lock blocks exceeds the specification of 20 MPa. The group of lock blocks in Walls A & B show good characteristics to resist the detrimental effects of freeze/thaw and deicing chemicals as represented by the Schmidt Hammer readings and the one air void analysis. However, based on only one air analysis, one cannot be sure what the air contents are in the remaining blocks in the wall. To achieve some kind of statistical confidence, 12 air content analysis tests (5% of the 236 blocks) would have to performed on the lock blocks to adequately represent the remaining blocks. In answer to your question "...are these Blocks acceptable as per the attached spec (S.P. 3.1.5, attached)?", I would have to say no because the intent of this specification has not been met. The specification quite clearly states that "Consistency of finish shall be maintained with the use of the same concrete mix and the same type of form oil for the entire project" and that is not the case with the blocks in question. The intent of S.P. 3.1.5 is that the lock block manufacturer order concrete from a readymix supplier, specifying the air, slump, maximum aggregate size and 28 day compressive strength and pour the lock block units in one contiguous pour and not the method used by United Lock Block utilizing returned concrete. A l so , using concrete from several different pours results in variations in the final finish and look of each block, reducing the overall aesthetics of the wall. 12 Figure 2.2: Example of Memeranda 27 tsl ^ ,p Hi •4 It * . $ <5 /> li v. - M o 1 & s> d 1 u -p d i i >« 6 •o <5 i 1 v. ^ * ft • •$> i <? vn o 0 0 % a cC - I - > . - . 88 <<J. • '.'CCj • i ' ^ : CC . <s • J • o «0 VP 6 O N CO Wttu-s CASTT t*l ft*t6-cautters Figure 2.3: Example of Project Diary for Progress Measurement 28 o V 0 S E Figure 2.4: Example of Internal Pay Item Report 2 9 I O o D l TO Q . z co 3 UJ O CO y- ui O D 5 O < H -z < D O a H ^ a: to a i < to i r 8 T5 -s a . •o c CQ a o. CN a. co c -a LL CQ 5 °-C © (TJ O g Q. I - in C CN » 3 > U J S. a_ C L O a> CO \D ^ 0L Q co "ro <u C L w a . ™ >. CO C L T J Q) ~Q-Q_ i/l ta QJ CD "a T— CO CN ai fX CO <u o ai c o o j5 O O CN Lt_ CN Q) Q_ QJ = O S Qi in Figure 2.5: Example of Pay Item Estimate 30 5 o C J C J ' O C J U O O C J IH > NO "a Q O O 2 Q 3 3 3 ^ to H tsi c o c C J O C J C J C J O C J U C J ON 0\ ON ON — — _ NO CN CN CN Q P H H ^ o o C~N 5- «-> O t/1 , 3 * I 2 o o U O 3 3 CJ o o CJ u o o o o o CN CN c_ ex CL, 00 OO 00 NO v i NO O O o £ Q Q Q O CJ O Q H f— o o 2 2 - 5 * Q . — — < < > 2 i I g a 3 < | •2 "g 5 3 b cj « ^ t— L - „ ~ e i -= _ < < n . c . a . d es cZ. _ — cc -a ^ a -£ ° -O Ja; •a o 3 "3 •2 S >N Q LU — =0 — o 2 o < < > o o c i H L L , a c a S pactic nmenl mbly 3= "o o op ren CJ < < • a i i < < 3 E L3 o CJ co\ O N 3 oo < Figure 2.6: Example of Quality Testing List 31 O •O ID -< C x a CD >. C ro I ~-> O X 10 u x 4-1 C 0) D C S o ra a cn cn _l 8 S_l LU F LO UJ cr a: -UJ CO , §< z UI _l c r < x o o < Q XI o I L U fCD i L U I D C I CD 1(3 1 < o ! • I 1111111111111111111 11111111 <C rt U_LA S o o a. 00 ( S S V W A 9 ) O N I S S V d l N 3 3 U 3 d u I o CM UJ CO < cn a LU a < cr CD _J UJ £ 6 O LQ Figure 2.7: Example of Quality Test Result 32 'liil-ilaTiiv TiiAi-ifii'iiiiiAiiuH '. •• .AMUIHOIIWAYU _ (::W.(I. r.iiliiuiJUu. 3 . ^ U A H V W i l l I K I H . : l ' U l l l " I - I I I U T X I I I A W U I ' I K Al IIJ i 'i luvlgly/lAL >M. IJ nU'J iJAfti ' .... / W ^ 1W/ . i ; u l l l M A i ; l u l Aiiiiiiiiiiii" W l . A l l TiJMr".':G 1iAl.11-: cl A s _t.fiL!2.t*!!itL. J l M s T G^Uc UiWirfr_. IM/M'I U U A I I M K 1Vi U11 UI in t i n u E __M|37| J o 7P lYWIIUl.l. AU I l l l lV l i l l S I I I I I U I A L — — A D D J M I V. :;Uiu;l I A I U I I ; — I U I A I . AMoUIII 1< ao 1T ?<L. -?s~ D___ "77 Gi JL lllitlnltr.l t nU . I (>n t U l f l U t l *l _ fin I frifil ill H'l||l<int ci»«l. MmJ-i," Imlliil kpljjM liolii» |mt (In/ ppi , |minnil lo' I M I M J nhcl loom. Mil ltinf|tU|< tut lionltl »iitl InoM. ( tli|iil(it>ipiil t)'l wrtnfilc tjr (il'ii ill iij* IpM In lli'jnil. Mnlnltnl Jillf-rlinnn* r 1 uI oil*filjrf nqiiltmif nl Id • • lid AlJ|i|ioi Ie J Lip lilvulcoii " ' •", >- 1 Htf\X ivi'ii MAUI: MUW-:I. i Jwni;i./.>iii; iii)i : | ' i ay; | ^ j , ™ ™ | AMUH-II [ rS> WV-tV „. __• / ' t . ^ W ^ 'Vfi'*1) -AMj-^  __„ y ?M. T ^ . \ \ C « s , -<^i...<&,-<) _ ii'r. !;Ui K ; I I A M U I ; — -l l l A l . 21. ' —> u-v 7 co-1 l s " CO 100 CO CM* 3? c i 7 2C i i i j s c h i i ' l k i i l l i - ivm-Jicmvin I ' W I U : I I A : ; I ; U ^COKC r,o;K Couple-* Co/vc/cV A>/. . !iUllCllAIU)li -I U I A I . l l l l A l l l l l ,' Hull Mm. T 10 Al.ioUI-l I' m i-rs .__\L£i i i i I I A M I : Cl A ! i ! l ll>.il|MT I.HI I IUAIIII IT U U M l t Y IW 011 Hi III I I l U l A l . A M U U I - I I -SLIP- I ~7WS'|Cy| : IUIALAMOUHI I 2.^1 <7f I ••• A C I ' t H »VAt. Figure 2.8: Example of Extra Work Request 33 Province of British Columbia Min is t ry"" TransfX and Highways o 1112 WORK ORDER/SUPPLEMENTAL AGREEMENT •CHECK IF H.177A < IS ATTACHED To: B.A. Blacktop l td . 303 East Ftplanarip Street t>,n. Pox HMO Nort-h Vancouver. B.C. (Cont.KUM-t N w m In FuM) V7L 4K6 Project No.:_JiaQ52rOTJilLl Projoct Description: | | ' Force Account [~^ ~] New Unit Item(s) j | Quantity Increase/Decrease Location: 1 | Non-monetary Change(s) | [ Delotion of Existing ltem(s) TNP, OF KAfiHFT Hir,HUAY_ JlETaO-CAilJUlA TO ST. •lOlUiS-SrflED-The following sections are to bo used to document the agreed upon amendments to the Construction Agreement antfor the Pmvin«rs authorisation ol Force I c c o T w o r t T v ^ - inapplicable). (Where Force Account Work is to be performed and is costed in block C. an e*plana,K>n o, the arcumstances . necessitating thai work must be provided in block B.) A. The lollowlng Uem. of work are added or dotted, or their quantllte. are amended, at the negotiated ralea .et below: ITEM NUMBER ITEM DESCRIPTION AJXylNCREASE/ DELETE/DECfiEASE UNIT Of MEASURE APPROX. QUANTITY UNIT PRICE EXTENDED AMOUNT Rel oc-at-i on-oMlvC— Hydro-duc-twor-k-at-PetFO Add L.S. —1 2-^09.^0- 2-r90a^ OO-Canada-aeeess-poad^ Supply-&^nstaH—i-/-371tfl-of—1 100-duct Supply &-it.sfcaH-+/—Blnt-eonerete-eneaseme it Supply-AHtts^aH^^fflaH-pi-Vastei-^ —:'_ B Th. following non-monetary Item. In the Conduction Agreement are l o b . amended ai Indicated: (Thl. .ecllon I. ALSO lo b. uaed to de.crlb. any Forco Account Work which I. being authored by the Province.) C . Th. following c o . I . o l Fore Account Work (de.crtbed above) which la being authorized by the Province: ESTIMATE OF COSTS (i.9.. Labour, Materials, Equipment and Miscellaneous) PERCENTAGE MARKUPS MARK-UPS IN DOLLARS EXTENDED AMOUNT (COST PLUS DOLLAR MARK-UP) TOTAL INCREASE OR DECREASE TO THE CONTRACT VALUE AS A RESULT OF THIS WORK ORDER: (TOTAL OF BLOCKS A AND C, PLUS ATTACHED H-177A IF APPLICABLE) ALL WORK SHALL BE CARRIED OUT IN ACCORDANCE WITH THE TERMS AND CONDITIONS OF THE CONSTRUCTION AGREEMENT THIS WORK ORDER IS ISSUED ON AuQUSf 1. 1 915 .19-Name (printod): H-S~—JaSSaJ Title: l!roject..Supervisor Signature: (J Where the Work Order is limited lo Force Account Work, the sections below do not roquiro completion. IF* Projuc. (irk* Conmwaion Agr»^iwN.iridudiog t)iVLi}«raim*nu WwrW b*if>g h*f*ln lo$*tr»< cal*d _ WKEflEAS: A. Th* Piovinc* uvJ In* OtVtiadM Into th* 'Contlrucllon lqi»*<n*rr %a t>ntitM »nd d**J |h* Provino* »c>po«M»j luid r*uJn*d lh» CooiiuXM lo ooo*truct th* Torvlructbn Ag>**rr*nTl; tnd B. Th* Provlnc* *nd th* Co«tf»a<K wkh to vrwrxl lh* ConalrixHon Ag.**m*nt, on Ift* l*>n» *nd ooodtilofw IIUK) »bov*. HOW THEREFORE lor v*Ju*£>»» oon>W*i«lbn, Ih* ptullat u loto**: t. Th* Contt.walon A(j'**m*nl k wnanded by Inaypotallng t>* abov* Ch*ng*(.) Into in* AUTHORIZED SIGNATORY FOR CONTRACTOR: IN WITNESS WHEREOF, THE PARTIES ARE DEEMED TO HAVE EXECUTED THIS WORK ORDER/SUPPLEMENTAL AGREEMENT ON -)• J! . )/?J <//.),//? SIGNATURE OF DELEGATED MINISTRY OFFICIAL: DISTRIBUTION: W M i - Accxxxtt P*y*04* C*A*rY • Con(r»ao. Pinh • ?it^a St**<v..ix * Bio* - P«4*J Flta Figure 2.9: Example of Accepted Ministry Supplemental Agreement F L r-L 5 n . - • i Baniet/Hwtiogs People Moving Project - 09052 P R O J E C T 09052, P E T R O C A N A D A T O ST. JOHNS MINUTES OF CONSTRUCTION M E E T I N G #f51 September 19, 1995 B.A. Blacktop Field Office Clarke Street and Barnet Highway Port Moody, B.C. In Attendance: Distribution: Don Lome BC Tel Engineering (rax 461-6746) Pascal Hirsig B.A. Blacktop Gord Sillers B.A. Blacktop Kees Van der Werff B.A. Blacktop Ron Lee Reid Crowther, Harriet/Hastings Project OS Singh Jassal MoTH. Construction Dana Warick MoTH, Construction Bemie Albert BEL To all attendees and Jamin Tao P C representing BC Hydro (fax SS3-4&3;) Bruce Haydcn MoTH, Geotech & Materials Bob Pearson MoTH, Area Manager Robert Hills MoTH. Roadside Development Tom Edwards MoTH. Electrical Tom Smith GVRD ITEM REMARKS I ACTION 51.0 51.1 Review of Previous Minutes no exceptions noted Utilities 51.1.1 BC Hydro/3C Tel i Pctro Can to Reed Point section; • E A B noted BC Hydro's contractor has switch power to the new but has no .51.1.2 51.2 51.3 50.3.2 started any removals. 3AB stressed tirneiy removals are critical to their schedule. • B C Tel has placed a 'RUSH' order on the anchor relocation at 70 T 80. B C Tel construction crew has reviewed the work requirsd and work will start this week. • Relocation of Petto Can's private power line will be done by EA3. BEL. and K-Line Contractors. 2. GVRD Pump Station to St. Johns Section: • B C Tel needs Transwestera (BAB's sub) to raise some services first before they can complete their work. This area is their 'second RUSH' area. • 3 A 3 explained BC Tcl's crossing for GVRD needs to be installed sow because wail £3 is about to start. BC Tel and BAB to complete purchase order arrangements. • The Crossing to Pacific Coast Terminals al 87 + 30 needs to be finalized soon. 3C Gas along View Street: * BAB explained this work will not start immediately. Submissions No new discussions. Schedule and Progress The planting schedule along the Vic-* Street property line near the EC Hydro iirte wiil be reviewed in October. Tais planting is a buffer strip for the crcpenies above. E?C B C T e l 2 C Te!/3A3 B C Tel B A 3 M o T H / B A B Figure 2.10: Example of Minutes from Weekly Site Meeting 35 Schedule Issues As mentioned earlier, the question of a up-to-date schedule from the contractor proved to be a weighty issue. It is important to note that at the onset of the project there was a schedule submitted (an overall timeline of the project); however the most current iteration of it was already one year old. After 30 days the contractor had not complied with the request for an updated schedule and The Ministry staff gave an official request for a recent schedule, on which the contractor had 14 days to react. The two weeks passed; no schedule was forthcoming and The Ministry threatened to invoke a $30 000 penalty clause in the contract. The schedule arrived shortly thereafter. Regrettably, the schedule was cursory at best, see Figure 2.11 for a 3 month schedule form the contractor, but more importantly it highlighted a consequential predicament. The public owner is not schedule driven in its documentation operation or contract administration function. Although it is not being suggested that the Ministry adopt a schedule driven climate in which to work, the author submits that since a contract clause requires the contractor to provide concurrent schedules that the Ministry exploit schedules where practicable. The scheduled activities presented in Figure 2.11 represent elements of the project and their corresponding locations. Pay items associations are not given on the schedule and knowledge of the work is required to make these associations. 36 Figure 2.11: Contractor's 3-Month Schedule 37 Pay Item Issues Progress measurements for pay items occur in several fashions: The Ministry surveys of placed quantities, field notes, weigh slips and invoices. Collection of data in some cases occurs daily, e.g. surveys of placed quantities, many others are not. Pay item reporting for the purpose of payment is usually done at month end. Quantities are documented physically on paper in the office. At month end this form, survey reports, field notes and invoices are reconciled and processed using a Microsoft Excel spreadsheet for the internal record for pay item progress (also the draft copy to reconcile the amounts) and then the amounts are entered into the software package called TEPE for shipment to the Regional Office on diskette. Figure 2.4 shows the Excel spreadsheet form used to reconcile pay items. Next, a file is opened for the month and all relevant documentation is filed with the pay item report. Such documentation includes all contract pay item amounts (used as a back-up check), and all extra work and supplement work orders. At no time are pay items documented against the activity with which they are associated. These associations, at best, are cryptic and vague and do not meet any immediate need of the Ministry with respect to month end processing. Quality Management Issues Peripheral to pay item recording is Quality Assurance reporting. The Ministry, being responsible to the public, takes great pains in assuring quality in the project. A consulting company, Reid Crowther & Partners Ltd., produced a quality assurance listing for The Ministry, as seen in Figure 2.7. This list has a hierarchical structure which almost 38 precisely correlates to the pay item structure; the initial intent was to mirror the pay items exactly. The items in the quality list are all the tests and inspections to be carried out by the Ministry and by all of the contractors and subcontractors. This list is quite expansive and involves repetition of quality testing for each pay item. Although the quality schedule structure is designed as such, the collection of quality reports and tests does not occur on an associative basis with individual pay items consistently or with activities. More accurately, quality reporting comes into the site office and is filed according to the general pay item to which it fits, or in other words the quality testing is filed against an element of the project. This element could be a specific pay item or it may not; it could be a specific activity or it may not. It could be a physical component, e.g. a wall, or it may not. For example, all testing on select granular sub base is filed in a dossier for select granular sub base, regardless of where it was placed. 2,3.2.4 Daily Site Report Issues The Daily Site report is one of the most frequently used forms on the job site and it has the ability to embrace a wide amount of data. However, more often than not the entire form is not filled out. Conversely, only specific aspects of the form are filled out; the most common being the section on daily activity/equipment/manpower. Compounding this issue are the inconsistent manners in which the various staff members record the daily data on the form. Figures 2.12 and 2.13 demonstrate the variability in the completion of Daily Site reports. In most cases a location is noted and an activity, the personnel and equipment associated with it are entered. The location that is noted is not always the 39 predetermined station number the Ministry has set out from the onset of the project, but rather is sometimes a pay item group or a location at the job site that has not been included in the standard list of locations. Additionally, another problem that is of concern is the inconsistent use of activities. Frequently, the activities presented by the contractor in his schedule are not used against which to log the various daily site pieces of information. Commonly, however, personnel and equipment will be logged against a location or an event that is not specifically on the schedule. Also, not all active pay items are recorded on the daily site form as being "active". They are more commonly recorded in survey reports and surveying diaries. However, certain pay items are recorded if they are directly related to an event transpiring. Notice too on Figure 2.12 that there is nothing recored in the pay item list and the bottom of the form is ususally left blank. In effect, the Daily Site form is a standard Ministry form without a standard method of being filled in and the previous inconsistencies result. 40 BARNET MWY. NO: 09052 r R O J K C T : CONTRACT C O N T R A C T O R : DA BLACKTOP R E P O R T N O : _ L D A T E : _ I N S P E C T O R : _T>. ^ T t S g K T y l . ? n p i AM T'.° 9- -I'M . J - / O C - -V e o t h e n A M _ g A . / / = L PM B A . / 1 J MANPOWiriVKOlHPMEMT IN USE/ACTIVITY ...-t.v S | .rt:iul mi l . ' ut nDv iJ au/atf i l l s . miy n>rCiall**d tqulfin i'AY ITEM 'I SIAT YO"STX ( 3 ^ C O - fiO*2C3 gQ-t op- 9 I T 8 & C Q -88->oo-SS-iOO .88*0° S 8 t ! 2 2 _ t l *5 Q^Cj__4£7-| - 98< oo t-rl 98. oo i/rl ACTIVITIES LoKDiQl* Tff[)r<-.', w/T/4 ScgSiS Ai°.Tl OS Ergon P//=t>T'o4<3g5S~ p HoE 6. i Kl S T o ' j T d S r e A f * ^ " (~>\i&e?>£G''tJ0r coKiCT-gtjer^yj O P VAJ.A.L<I _ 5 eeSvDi »J<i^ .S.&S'3 P I ) H P M A K - > , S&^g L. - 7AK jSVSSStS/AjCr..SC^K. A>AO<- - V / p U J U A O L I A J O S C V & B T O M/( L--7AS EQUIP/MNPWR C^SO G C A T • • ^ A " Q (y C A T T A U O C H S &A EXTRA WORK HAUL i|uipnei\t HiiM|')0wer Hrs Moterinl Cut S / S Fill S /S Vol /LC — visum,':: IIM MIL OUALITY ASSURAICi: ll. P.S. SIGNATURE i^P. SICHATURE/^Q~/4^Z_ Figure 2.12: An Example of Filled Daily Site Form P R O J E C T : BARNET HVY. C O N T R A C T NO: Q9Q52 C O N T R A C T O R : DA BLACKTOP R E P O R T N O : _ DATE: v ^ . z y ^ I N S P E C T O R : ^ . T e n p r A M _ P M Weather: AM_ PM M A N P O W E R / E Q U I P M E N T IN USE/ACTIV ITY (n«l<« « p « c M nutr o f «()>^>n«nt novrd on/off l i t * . «nci any spccul l t td cqutpnritt In u.t) CAY IT/M STA. TO STA. ACTIVITIES EQUIP/MNPWR C A T <S~Q^> C-5 Z. CJIJT q i t -ti**«o EXTRA WORK I'.UII N o u Lnrn-Unn Lnuipnent Mrs Hnnpower Mrs HAUL Material Cut S/S 1 Fill S /S | Vo l /LC VISITORS! UN Sil l" . QUALITY ASSURANCE P.S. SIGNATURE ' " S P . SIGNATURE 1, Figure 2.13: An Example of Filled Out DaUy Site Report Site Records (photos, etc.) As mentioned earlier, the on-site staff are encouraged to take photographs of the daily occurrences on the job site; however, currently this leads to a large number of seemingly random pictures in a box. Furthermore, there is a large body of data filed away in filing cabinets at the site office. The current process undertaken by the staff to correlate these diverse records relies exclusively on their knowledge of the information. There are no physical associations among records and querying the record set is impossible, especially if no fore knowledge of the project exists. 2.4 Observations about Original System Design and Field Realities Since one of the objectives of this work was to comment on the prototype versions of English's routines and suggest improvements, it will be advantageous to discuss problems found during the site trial with respect to the current routines. Discussions of the issues will be based on a comparison between the original method REPCON possessed to handle the issue, and of the method that was used to actually handle it in the field. From this argument enhancements needed to the routines will be outlined in Chapter three of this thesis. 2.4.1 Scheduling and Daily Site Tracking Once the obstacle of obtaining a schedule was overcome, the next step was to begin by making all the pay item associations with the given activities. This facet was achieved by retrieving pay items from plan drawings and asking for assistance from 43 Ministry staff. It was hampered in a minor way by the author's own inexperience with such a procedure. Subsequently, associations between pay items and quality tests were established. With all associations instituted in the schedule, project documentation was initiated from The Ministry Daily Site reports. Problems began to emerge almost immediately. The activity view of the project, against which the monitoring was being done, was not sufficient for the needs of REPCON. The Ministry staff did not log their data (site conditions, equipment, etc.) consistently. Much of the information they chronicled did not specifically relate to a given activity or location. In many instances the statistics were noted against pay items or a location supposedly not active on that day. It became apparent that the schedule was not always indicative of what was actually transpiring on the job site. Since the Ministry was not concerned with the actual "scheduled activities", i.e. they were unaware of what was presumed to happen in the detailed sense, they often did not report on activities in great detail. Instead they reported on events often amalgamating several scheduled activities together. As a result, trying to discern the circumstances and attribute them to the given activities on the schedule proved to be a time consuming and error prone chore. Another issue that surfaced during the site trial was the huge activity diary forms. Similar to the Ministry's Daily Site form (filled out by Ministry staff) REPCON produces a daily activity diary which allows a site supervisor or other appropriate staff to record the 44 day's events. This form was designed to allow for everything that could possible happen on a daily basis to be included on it. Consequently, after all activity and pay item associations and pay item and quality management associations were incorporated, the resulting "form" had the potential to be very lengthy. In one instance the activity diary was in excess of 15 pages. This unwieldy document lost its practicability; however, it is significant to note that the significant length of the report form arose from the quality management associations with pay items. This process was implemented based on work completed from English's thesis. 2.4.2 Pay Items The original process through which pay item progress measurements were entered into the system required proper associations of pay items to activities. Then on a daily activity basis pay items could be documented. However, paramount to this arrangement, is the concept that all pay items that could possibly be active have to associated to the applicable activities. This situation demonstrated itself to be not the normal situation for the test project. Pay items were reported on and no previous association to the relevant activities existed. Pay item progress was being tracked outside of Daily Site. The original REPCON approach had pay items pointing to activities which pointed to date and progress. Therefore, this meant that each pay item had to be associated with at least one activity in order to record progress. This is fine if the project is schedule driven, and well scoped schedules are formulated; otherwise, it is a major problem area. 45 2.4.3 Quality Management Presently in REPCON the quality management tests are entered in a straight list form, i.e. all quality tests are contained in one list. Again, currently in REPCON it is possible to make associations between quality tests and pay items. These associations are then utilized through the daily site routine. During daily documentation of pay items it is possible to tag quality management against a particular active pay item. For this feature a quality test Pass/Fail criterion is used; an action required flag can also be set. To date this is the extent to which the quality management routine is used. This contrivance does not meet the needs of proper quality management. The only way to access individual quality management records for updating is to descend through the Daily Site routine via scheduled activities and associated pay items. In reality, this structure becomes too cumbersome and limited as quality management is not recorded on a daily basis per se. Rather, we want the ability to freely enter quality management data when it arrives at the site office and make associations with other pieces of data (such as activities and pay items). As mentioned earlier the activity daily diary form generated can be very long with all the associations among pay items and quality management. This predicament originates from list of quality assurance and control tests from Reid Crowther and Partners Ltd. This catalogue of tests is designed to mirror the pay item list exactly; however, the result is much redundancy in this structure, which in turns leads to the extensive activity diary. 46 2.4.4 Records Management The first implementation of records management in REPCON was the initial attempt to begin to link all the various "hard" facts of a construction project, such as photographs, quality testing results and correspondence, to the diverse components of the project such as scheduled activities, locations and pay items. The specific record can also be associated with other records; such as might be done for a series of photographs on one topic. This feature has the capacity to allow for all relevant documents to be viewed on screen once they have been scanned with the proper hardware. However, it is not necessary to have to scan all records to use the records management feature of REPCON. It is sufficient to identify the record as to the type and then make the appropriate associations to the project components. The physical records are individually recognized to conform to one of the REPCON categories in the following list. • Photos • Videos • Letters/Memos To • Letters/Memos From • Certificates/Forms • Minutes • Plan Excerpts 47 This feature of REPCON was the only component that allowed for associating of records with other project aspects and the viewing of them once they were scanned. This constraint limited the practicability of having the records on line. If a problem arose with a certain activity and the user were accessing activity information from the activity routine he/she would have to exit out of it and enter the records routine and query the system appropriately for records pertaining to the desired activity, similarly for the pay item routine. 48 Chapter 3: System Design and Modification 3.1 Philosophy of Multiple Views An individual project consists of multiple sets of data representing the entire project and because of this immense collection of data, the capability to see all of it at once is not only impracticable, but next to impossible. Accordingly, this data can be compiled into manifold units, and each of these assemblages represents a distinct view or account of the project. Therefore, these qualifying factors give rise to the concept of multiple distinct views of one project. 3.1.1 Definition of a View Simply, a view consists of enough data about a particular aspect of a project to adequately represent it. The view should contain enough information to allow for a discrete view to certain specific data, in effect, to get a realistic snapshot of a project in a given time frame (from a day to the duration of the project). However, what constitutes 'enough information' for a realistic view? If we are to consider a view to be request specific, i.e. only pay items, then only pay item relevant data need be available for the user. Alternatively, if we are to consider a view to be a window to the entire project with emphasis on one aspect, e.g. daily site, then all project data must be somehow accessible to the user regardless of the primary view. For this thesis, we will consider the former to 49 be the definition of a view. However, this is not to imply that associative links from view to view are not possible. These link are indeed present and are primary to REPCON's success as a total project management tool. 3.1.2 General Philosophy By assuming the first definition of a view we are able to address a wider range of projects. For example, the Ministry project used as part of this thesis is not monitored on an activity basis but rather is pay item driven. Each view available in REPCON theoretically should be able to exist by itself if the user so chooses. However, the added dimension of being able to link all the views together establishes a very powerful project management tool because it creates the ability to formulate composite views of a project. The user will be able to track separately many components of his/her project, yet still be able to access any information conveniently. We would like to be able to represent a project as simply as possible with as few views as possible. However, in reality the fewer views that are included, the more awkward it becomes in representing a project properly. Therefore several distinct views become prevalent: the physical view; the activity view; the pay item view; the daily site view; the records view; the quality view; and finally the change order view. These views are displayed in Figure 3.1. 50 Pay Item View st and As-bu Activities View (Process & As-built) Change Order View Physical, Cost, Process, Aj JJIUIIL Physical Model View (Physical/Environmental Parameter Model) Quality Management V i e w J ^ ^ Records View {As-built), Figure 3.1: Project Views 51 3.1.3 Advantages and Disadvantages of Each Distinct View It is no surprise that each view carries with it advantages and disadvantages that set it apart from the other views. No one view can be considered complete, otherwise the need for separate views does not exist. Consequently, each view emerges to suit a particular niche in the project. Activity View The activity or process view can be considered the intrinsic component of REPCON. Activities are the backbone of a project schedule, the building blocks. They become very efficacious in project management; they break the project into logical constituents for easy associations. This is their main advantage as many other components of other views can be linked to activities. Regrettably, though, there is an express disadvantage to the activity view: project monitoring that is not activity based is difficult, as is the case with the public owner. Pay Item View The pay item view has its advantages centered around the financial aspects of project management. The pay item view allows the user to categorically organize all cost accounts and track data against them. However, disadvantages become evident when there is no direct association between an activity and a pay item. In other words, if no previous association between and an activity and a pay item has been established, then it is not possible to make progress measurements for that pay item, at least as implemented in 52 REPCON based on English's work. The capability that is required for the pay item view is to be able to make progress payment for the pay items outside of the schedule of activities, an extension to the prototype system offered by this thesis. Daily Site View This view of the project can also be considered the as-built view of the project. Through this view all the project data is archived to create a record of exactly what transpired at the job site. The fundamental advantage of the daily site view is that it allows the user to document the project on a daily basis to a very intricate level of detail. Once the daily site view is set up the user can begin monitoring project progress to include many of the other views. He/she has the ability to log everything from activity status to site conditions to quality tests performed. Unfortunately this advantage of great detail results in a frustrating disadvantage: too much data. Another disadvantage corresponding to The Ministry procedures is the predicament that not all data that is listed on the Daily Site form is collected on a daily basis or is it directly related to the scheduled activities, and finally, no one person is responsible for the collection of data - it is a divided responsibility which makes use of multiple data collection formats. Records View The records view of a project is a peculiar one. It is probably more accurately described as a view in support of other views. This view provides the means to organize aspects and individual pieces of data from the other views in order to create reports to suit 53 very specific situations. Therefore, by virtue of this uniqueness, the records views emerges as a distinct account of the project. Because construction projects generate an immense amount of "paper" documentation, there is a need to have it systematized for easy access. The records view in REPCON facilitates this organization: an advantage. Conversely, disadvantages to the records view encompass such issues as the need to scan documents and the knowledge needed to provide sufficient associations with the other aspects of the project and other records. Quality View The advantages of having a distinct view of a project that is geared to quality management is the ease with which such information can be accessed. Since many quality tests can occur on a repeated basis for many activities, according to the Reid Crowther & Partners document on quality, there exists the possibility of a vast body of data. Prior to this thesis work quality test results were documented as associations to pay items. This set-up proliferated into a tremendous amount of daily documentation needed. As an example, the Ministry project studied generated a Daily Site Diary consisting of 17 pages due mostly to redundant associations between quality tests and pay items. A disadvantage to the quality view is that not all quality test results are easily associated with either a distinct activity or pay item, at least with respect to the results as they are reported. Change Order View 54 There is some debate as to the relevance of a separate change order view. Currently, the Ministry does not track change orders with a highly refined process; however, over the long term, the need exists to do so, and in a way that links change orders with the other views. Therefore, broad change order features necessitate the creation of a comprehensive change order view. The change order view is plagued with many disadvantages relating to the inconsistency of terms used in change order management. 3.1.4 Overlap of Views As anticipated, these various views cannot exist exclusively by themselves. Rather, they compliment each other to render a complete and comprehensive representation of the project. One of the chief benefits of the multiple views is that one integral computer software package can be very effective for a wide spectrum of users. Each distinct operator with his/her own set of criteria can opt to access the relevant view to facilitate his/her requirements of the system. 3.2 Design and Modifications of the Views The following sections of this thesis identify the changes and or modifications made to the various features of REPCON. Certain sections will describe future work that is suggested based on this research. 55 3.2.1 Activity View Modification One of the significant additions to the activity routine of REPCON is the ability to associate project records (such as photos, minutes and letters, etc.) and view them from within that routine. This augmentation is a great benefit for the ease of appreciating the record-activity relationship. Figure 3.2 indicates the flow of events for this feature. No longer is it necessary to exit up through the activity routine and descend through the record routine to associate and view activity records. By allowing the associations of activities and records, and the viewing capabilities of the records in the activity routine decisions can more easily and expediently be formed. This situation demonstrates the overlap of more than one view within the overall construct of the project. 56 T—I I—I 1—( ± 3 O O O <U § p <S 1 s i a -s 8 «-a M O O O CO Q •< pj O H ft1 lent P O a. Daily Site Pay Item/Acct Apply for Payn Change Orders Records is Resources Cash Flow Sched ofValues PLANNING & View Batch Update Macros Reports Summary Sched PROJECT Project Data ( Calendar Rept Manager Pay Item/Acct Select/Sort Reports SYSTEM Project Files Standards Configuration Stnd Projects Utilities Exit I co © B s • mm < JS OD S o e o o o on O e < s Ml 57 A second aspect of the activity routine modification relates to selecting and sorting records from the project routine. The records routine performs its selecting and sorting to generate a list of records attached to one or more activities. In other words, given a particular activity, produce a list of all associated records. However, this case is not always the desired condition. From the select-sort feature in the project routine it is now possible to elect to produce a list of activities that are associated with a particular record or records, i.e. given one record or records, what is the resulting list of associated activities. This scenario is of marked importance because one distinct record could affect numerous activities (provided the proper associations were previously made). By querying the select-sort for all activities in question it takes the onus off the user of having to remember all the previous associations made linking the record to activities. Conversely, the record select-sort routine would require the user to rely on his/her antecedent knowledge of prior record activity association. This knowledge could possibly be negligible if multiple users were operating the system. 3.2.2 Pay Item View Modification Based on the findings in the field, the Pay Item view of a project should be enriched. One issue deals with the direct tracking of pay item progress outside of the Daily Site routine. Considering the Ministry customarily performs their formal pay item progress at the end of a progress period (usually a month) and that pay item progress associations with activities are cryptic at best, a question that has to be addressed is whether a separate data collection format for pay item progress should be added under the 58 Daily Site routine, or added to the Pay Item routine itself. Also needed is the ability to prepare progress claims, consolidate them, time window them, etc. To respond to this situation it was decided to augment the Pay Item routine instead of altering the pay item progress aspect of the daily site routine. The first iteration of the pay item progress only allowed for progress measurements to be entered for pay items which were previously associated with activities. Figure 3.3 represents the flow for Pay Item Progress through activities. Also, when the measurement was entered, it has to be against an associated activity only. Consequently, if a pay item became active during a progress period and there was no former association or if the activity was not active in the time window (on the schedule in the Daily Site feature), no update measurement could be entered. This limitation became an issue and the modification was added. The system now allows for the option to either proceed with measurement as before, or make progress measurements against the pay item only, or the combination of both if the situation dictates. Figure 3.4 represents the flow for Pay Item Progress outside of activity associations. By enhancing the pay item progress measurements as such, the system now responds to a broader spectrum of situations. 59 61 Further, another addendum to the pay item routine is an adapted reporting feature in the routine as illustrated in Figure 3.5. The user is able to now produce a report that can have any one of the following. • A progress measurement history of pay items • This feature is designed to allow the user to choose the time window in which he/she wishes to see the history. In other words, the user can tell the system to print out an entire progress measurement history on a monthly basis, or for a single month, or any other monthly time window in between. Included in this feature are: • the date of the progress measurement, • the method of measurement, • the code of measurement, i.e. associated activity breakdown or no breakdown, • the location range if applicable through activity breakdown, and • the quantity per location, or total quantity • A monthly summation of progress payments and measurement quantities for the pay items for a selected month or months. • This selection will produce a report that shows the pay item quantity progress measurements as well as the incremental cost involved for the time window chosen. Included in this feature are: 62 the progress measurement date, the measurement quantity, the pay item's unit, the pay item's unit price, and the monthly payment, a total for each month in the time window • A pay item cumulative payment to-date feature. • This feature exhibits a report that shows all the pay items that have progress measurements associated with them and the to-date totals for each of the months in the time window. Included in this feature are: window • Finally, if a time window of one month is chosen, at the end of the pay item list a summation of the to-date progress payments is provided. • This feature gives a total for the monthly payment in the progress payment monthly option and the total for the cumulative payment to date. • each month in the time window, and • the payment of each pay item for each month in the time 63 64 Despite the supplementary features added to the pay item routine, a design consequence is manifested, once associations between pay items and activities are made and then progress measurements against activities are entered, what happens if the pay item activity relationships are altered? Although this situation is easily avoided by not altering relationships, it still exists and it must be appropriately solved in future generations of REPCON. Similar to the Activity routine, the Pay Item routine now also provides for direct associations with records. The direct ability to link a pay item to an existing record can be completed under the associate-with-records window in the Pay Item routine as represented in Figure 3.6. 65 3.2.3 Daily Site View Modification The major improvement to the Daily Site routine is the reporting feature. There is a tremendous amount of information collected that can be collected in the Daily Site feature of REPCON. To fully utilize all this potential data it is necessary to produce report documentation as output. Figure 3.7 represents the system flowchart of events relating to standard report generation. The system currently has a series of predetermined data reports refined as part of this thesis and a report generator feature new, in support of this thesis. The deliberated reports are as follows. • Daily Site Report • This choice produces a report that contains all the information entered in the Daily Site spreadsheet under the scheduled and non-scheduled activities. It is printed out based on a time window constraint. The user stipulates the duration and a separate report for each working day in that period is generated. The user also has the opportunity to allow or disallow several options in the report, included in the following list. • exclude activity code • include non-worked days • order activities by location • print responsibility code index • print problem code index • print schedule activity/pay item/quality management index • include activity pay item 67 • include activity labour and equipment Problem Sources Report • This report gives a detailed summary of all the problems that occurred during the project. These problems are the ones documented through the problem code index available in REPCON. This report uses a date constraint as the criterion for printing. History Report • The focus of this summary is to present to the user a synopsis of the documented problems and their reprecussions relating to activities. This report uses the date constraint as a printing window; however, there are also a few options for the user to consider. They are • order by report period dates • exclude remarks (entered through the daily site schedule) • problems assigned to responsibility code Time Adjustment Report • By selecting this digest the user can produce a report that focuses on the man-hours and days lost during noted problems. Again, the reporting is bound by entering the date time window. Work Environment Report • A work environment exclusive synopsis can be produced by selecting this report. Included in the environmental report are the site conditions: ground conditions, storage on site, and access to site. The data time 68 window is again utilized. The user has the option to include non-worked days as well. Work Force Report • This report gives details regarding the work force that was recorded under the general project in Daily Site as opposed to the work force that is entered for individual scheduled activities in Daily Site. It is important to note that all work force data should be entered here, and then supplemented, as required, through activity entry. The user has the options to select all responsibility codes or to order by responsibility code when he/she prints the report, and once more it is printed out in date time window. Each of the following reports give exclusive particulars for the aspect of the Daily Site feature their name suggests. As previously, the individual reports are produced using the time window date constraint, each also has the option to include non-worked days in the report. • Blasting Report • Survey Work Report • Inspections Report • Visitors Report • Accidents Report • Deliveries Report • Site Instructions Report • Equipment/Rentals Report: for equipment and rental not entered under scheduled or non-scheduled activities • Miscellaneous Notes 69 so © o. u « c 03 •»-> </3 V s M) 70 To compliment the predetermined report forms, a report generator was added to the Daily Site feature of REPCON as part of this thesis work. This first generation report generator endeavors to place, in the hands of the user, the flexibility to tailor reports to specific needs not addressed by the other reports. The system flowchart for the report generator is given in Figure 3.8. The subsequent list only presents the options that are currently obtainable; however, future work will augment the possibilities for inclusion in the report generator. There is a multitudinous amount of data befitting a report generator still not addressed by this feature, such as the myriad of comments that can be logged against pieces of data in the Daily Site report. After selecting the report generator feature the user next must choose the report contents profile option in order to begin composing a report. Having done this step, it is necessary to add the profiles by name to the list of all profiles. When the user attempts to actually produce the report, the profile is selected by its name. Once the name of the profile is existent, the user opts for the contents command to begin to tag data to be included in the report. The ensuing list presents the current selections available for inclusion in a report. The first column indicates the length of field required for the particular option to the right of it, while subsequent columns give the actual piece of data. • 14 Weather - Sky Conditions • 12 - Temperature • 8 -Precipitation • 10 -Wind Speed • 9 - Effect on Progress • 7 Site - Ground Conditions • 8 - Storage • 9 - Accessibility • 8 Daily Work Force - # of Supervisors 71 8 - # of Workers 7 - # of Traffic Controllers 6 - Crew Sufficiency 7 - Skill Level 9 - Turn Over Level 9 - Overtime Amount 9 Daily Equipment - Quantity 10 - Status 6 Activity - Progress Status 8 - # of Supervisors 8 - # of Workers 7 - # of Traffic Controllers 6 - Crew Sufficiency 7 - Skill Level 9 - Turn Over Level 9 - Overtime Amount 9 - Equipment - Quantity 10 - Status 46 - Problem - Responsibility Code 31 - Man-Hours Lost 31 - Days Lost 73 - Pay Item 6 Extra Work Order - Progress Status 8 - # of Supervisors 8 - # of Workers 7 -# of Traffic Controllers 6 - Crew Sufficiency 7 - Skill Level 9 - Turn Over Level 9 - Overtime Amount 6 Back Charge - Progress Status 8 - # of Supervisors 8 - # of Workers 7 - # of Traffic Controllers 6 - Crew Sufficiency 7 -Skill Level 9 - Turn Over Level 9 - Overtime Amount • 13 Survey Work • 77 Blasting • 77 Inspection • 32 Visitor • 77 Safety/Accident Log • 44 Delivery 73 The succeeding step, once appropriate options are tagged for incorporation in a report, is to select the Reports command to display the synopsis of data. Like the preceding reports, the report generator also exploits the date time window as a bound on the report. After the time window is selected, the user simply chooses his/her intended profile name, confirms it and the report is created. It is of significant importance to note that there is the possibility to formulate reports that can become quite clumsy and unmanageable. Once enough options are tagged to fill the width of paper, the remaining tagged options will begin on a second line. This produces a wrapped around effect and the report becomes more tedious to read. Nevertheless, the freedom of selection is a significant advantage for the report generator. After future iterations of the report generator are programmed, the remaining, presently unattainable, data will greatly add to the usefulness of this REPCON tool. 3.2.4 Records View Modification It is, with no doubt, that the records view of a project is of considerable importance. Many of the physical occurrences, such as quality issues and unexpected problems, can be documented in the Records routine. And this importance is of even greater consequential value in the future of a project after it is finished its construction duration when the possibility for claims arises. Therefore, a complete and thorough records keeping feature is not only needed, it will prove to be a principal asset to future project analysis. If the time is taken at the construction phase to properly associate the physical records among the vast amount of project data, a huge service will have been 75 provided to the future user. The Ministry will no longer have to rely on fore knowledge of a project to extract relevant facts from an immense, seemingly random collection of data; rather they can now be equipped to prepare documentation for claims support by exploring the system with the two operators, and and or, to complete data searches for conforming records. To add records to REPCON, the user must categorize the record into one of seven predetermined types of records. Once this determination is completed the record is assigned an alpha-numeric code. Each record begins with letters corresponding to the category into which it fits. The following list exhibits the seven classifications and the convention adopted for the alpha-numeric code. • Photos PH • Videos VI • Letters/Memos To LT • Letters/Memos From LF • Certificates/Forms CF • Minutes MN • Plan Excerpts PE After the category is selected the user is left to his/her own discretion on how to complete the alpha-numeric coding; however, for ease of searching the system logically, it is best to embrace a numeric sequence after the category code (a suggestion for future 76 work is to have the system automatically enter the record number). Understandably, the system can only function as efficiently if suffucient effort is put into establishing proper associations among the records and data. Currently the user has the opportunity to affiliate each record with a variety of project aspects. These aspect are currently limited to the ensuing list; yet, future work should enhance this list as more features of REPCON become available, such as a new quality management routine and new change order management routine. • Activities - one or many • Locations - one or many • Problem Codes - one or many • Pay Items - one or many • Other Records - one or many Once these associations are completed any user is readied to perform searches of the project data. The flow of events is illustrated in Figure 3.10. He/she begins by selecting the Record Report Generator command, and next continues by selecting the Select-Sort Profiles command. Like the report generator in Daily Site, it is necessary for the user to add the select and sort profiles by name. When that is completed, the user selects the Contents command and he/she can begin to create a set of search criteria. The Boolean operator and is used to narrow a search and the operator or is used to widen a search. Next a key code is selected as the initial criterion for association or query. These key code preferences and what they represent are in the following list. 77 • RECTYPE • RECCODE • RECDATE • ACTCODE • LOCN • PROBCODE • PAYITEM the type of record: photo, video, etc. the record code: the alpha-numeric code from the user the record date: the date that was entered for the record the activity code: the REPCON assigned code for all activities the location code: the code stipulated by the user the problem code: the codes used to identify common problems the pay item code: the user determined numbering system 78 Once one of the previous codes is selected, the user must choose a condition to relate the key to the coding system adopted. These conditions will allow the user to conceive a report of a project aspect or view that fit his/her needs. For example, the user could opt to select all the records that are associated to one activity or one pay item, or he/she could decide to create a report containing only photo records entered on a particular date for an individual location. The possibilities are endless. These condition choices follow as well as the corresponding number of values needed to complete the search. • EQ - equal to • NE - not equal to • GT - greater than • GE - greater than or equal to • LT - less than • LE - less than or equal to • WR - within range • NR - not with in range one corresponding value used one corresponding value used one corresponding value used one corresponding value used one corresponding value used one corresponding value used two corresponding values used two corresponding values used Having formulated a set of search criteria, the user can now decide if he/she wants to sort any of the data in ascending or descending order. This task is effected in the Sort routine as demonstrated in Figure 3.11. It is similar to the select routine, in that it prompts for a key condition. Next, the user must select either ascending or descending order for the desired condition. The user is also capable of ordering more than one key 80 condition hierarchically. If he/she so chooses to add another key condition, the records are first sorted according to the initial key condition order and within that order the other records are sorted according to the second and subsequent choices. For example, the user could resolve to sort his records according to an ascending pay item code criterion, and still sort the record for each pay item according to perhaps a descending date constraint. Therefore, he/she would get a list of all records linked to the hierarchical list of pay item, but if more than one record existed for a pay item they would be listed with the most recent record first. Finally, with the select, sort and contents profiles completed, the user is in a position to now produce the records report. The Records Report command is selected and the user chooses the Select Profile name, the Sort Profile name and the Contents Profile name. These are confirmed and the report is generated. 81 8 2 3.2.5 Quality View Design From site trial observations, the quality management reporting does not occur on a daily basis per se. Although, in effect, it could be thought of as a daily event, it is not consistently recorded on the daily site report. Therefore, by solely having the quality reporting feature buried under the active daily pay items, it will not be effectively utilized. A separate routine necessitates creation to augment the current features. It is no surprise that The Ministry takes their quality assurance very seriously and currently there is not any effective way of making use of the vast amount of quality data currently available nor, apparently, do The Ministry exploit this vast amount of data. This routine could be thought of as an extension of the daily site reporting feature. Since the quality test number and pay item numbers coordinate with each other, the links are easily made. Once these associations, and pay item activity associations are done, and the schedule is established (if applicable), the system has the capability to produce a listing of quality tests that should be done, or reported, on any particular day. By treating the quality routine in this fashion it would be possible to access it without having to descend through activities and pay items in the Daily Site routine. Effectively, quality management can be thought of as a separate view of the project. With this "separate" view of the project, quality management updating can be done as documentation arrives in the office (which is sporadic and does not coincide necessarily with the activities that are currently in progress). It is not essential that the current quality feature (mainly the Pass/Fail criterion in the daily site routine) be abandoned, but the 83 system could be augmented to better exploit the quality data. By just including the pass/fail criterion no further knowledge is gained: whether the test passed or failed is known from the hard copy and should have by this time been acted on. The author's feeling is that if the only way to enter quality data is at the daily site pay item level, it just will not be done on a regular basis and therefore much knowledge will be lost. Currently, the system only allows for viewing of one test result at a time. By developing a separate quality view of the project, immediately the user will be able to see trends in quality results without having to individually glean that information. Since the Ministry has a quality management listing (from a consultant) that mirrors the pay item list numbers (as it does for all its projects), it would be advantageous to employ the current pay item tree routine to represent these quality tests. By applying the pay item tree routine to the quality management routine many possibilities become available. However, before these are discussed it is useful to identify the attributes of the quality test object. The basic attributes that need to be included at a minimum at the definition stage would be • a quality test number (internal to REPCON - system number) • the test description (test name) • responsibility code (name and number) • frequency of the test • tolerance or acceptable criteria 84 These features will be entered from the Define/Modify window of the Quality Management routine. They represent the "base" information about the test or the standard information (a possible standard list of The Ministry tests could be exploited). The next window that could be accessed would be Results. Under this window the more specific details of the quality tests can be entered. It is through this routine that the particulars of the test can be entered. The Number of tests can be increased each time the test is performed thereby creating a new file for each new test. The details should include but are not limited to • number of individual tests performed (e.g. 6 nuclear density tests) - for each test: • date sampled • date tested • tested by • specimen/sample type • source/supplier • particulars • comments • the test number (external to REPCON) • location of sample/test • pass/fail criterion (from daily site as well) • action taken (specific) • individual comment Another window that could be utilized is Associate with Pay Items (to coordinate with the Pay Item routine association with Quality Management). Also it might be beneficial to also provide a direct association with project elements. This might be more 85 beneficial from a Ministry perspective as they do not directly file their quality reports according to individual pay items. Rather they are filed according to material type or work item (i.e. non-leaf item in pay item structure). The Ministry filing indicates that most quality results are grouped by what general pay item is affected. For example, all testing relating to Wall 1 is kept in a separate file in order of occurrence. Wall 1 is a physical element of the project. It may point to pay items or vice versa, activities or vice versa, etc. It would probably be more beneficial to link quality test to the element leaf rather than the subsequent sub-levels in the Pay Item Structure. By doing this, the idea of inheritance is employed. Instead of repeatedly entering the quality test attributes for all sub-levels of the Pay Item structure or alternatively making the same associations for the individual pay item, the association should be made at the non-leaf level and all lower pay items would automatically have these tests associated with them. This routine leads to the next window: Testing. This feature could also allow for listing of tests that need to be done, thereby facilitating a check system of tests that are done compared to tests that are still outstanding. Since many tests are done on a random basis, the routine should also be capable of tagging certain tests to be included in a quality test list of all necessary tests. Therefore, another window that could be included in the reporting feature of quality management would be a Listing/Reporting window. This window could incorporate aspects such as lists of all tests, list of all tests of a particular type, a list of all tests to be done on a specific day, a list of tests by supplier, etc. This 86 This could be facilitated by a quality profile. Report generation needs elaborating: what criteria are used to compose reports? Such criteria should include: • location of tests • type of material - pay item • date • supplier • Pass/Fail There is a wide range of quality testing that takes place on any given Ministry project. This list includes the following, but is not limited to: • densometer test • gravel tests • sieve analysis • aggregate gradation • compression tests on concrete cylinders • moisture values • density (max. dry) • air content/void analysis - ASTM C457 • Schmidt hammer • visuals • memoranda/descriptions • pavement smoothness • asphalt density and pavement thickness • compaction • Marshall Properties • Hveem data • concrete inspection • field density (nuclear) 87 Considering this large and varied list of quality tests and their associated data the issue of a one-fit-all screen to handle each individual test becomes apparent. Do we make a data entry screen that has the capability of handling all possible information for any given test results or do we tailor the system to handle standard industry tests with a general "form" for other possible unique tests. In other words does the user, for instance, click on "Standard Proctor" test and then input the relevant data or would the user simply enter "Standard Proctor" in an appropriate field? The author has no immediate answer for this. Future improvements to REPCON which include aspects that are as user friendly as possible leads one to consider that we should include as many standard tests as possible. However, this will result in the formulation of a complex quality test object. 3.2.6 Change Order View Design The main objective in the implementation of change order management, in REPCON, is to provide for an effective way for tracking the change orders that occur throughout a typical project. This design will include those aspects of change which impact on planning, scheduling and control. Therefore, the aspects that need to be addressed include, but are not limited to: • time consequences (impacts on the schedule) • adjustment to costs (statements of incremental costs, apportioned by time) • association with activities (impacts on activities - added, deleted, modified) • association with pay items (line items for changes) • association with responsibilities (subtrades) 88 Important to this guiding principle is the perspective from which these changes are taking place. The systems needs to be sufficiently robust to handle views for the client (architect/engineer) and for the project management staff as well as the general contractor. In other words the change management system must incorporate two perspectives: one that is giving orders and one that is receiving orders. This latter statement is a simplistic analogy to demonstrate the main difference of perspective. In theory, the client only deals with one point of contact: the general or prime contractor ( project management). Consequently, the impacts on the subcontracts are not of direct concern to the client. However, the general contractor is concerned with not only the client viewpoint, but also he is concerned about subtrades as well. The points that must be addressed involve • when a change order is entered, at what point • who enters a change order • when is an extra work order used as opposed to a site instruction or field order We should solidify some definitions to use in REPCON to simphfy our understanding and reduce the confusion of inconsistently used terms, i.e. use FO for these situations or use CO for those, etc. The following sections describes where each type of order could be used; they are not meant to be in any hierarchical structure. 89 Field Order (FO) • it corresponds to an extra work order in its simplest form. i.e. it involves an activity that has float and the associated cost is none to minimal; a site instruction from the architect when he/she is on site which is usually not formally documented. However, it could lead to a EWO or change order if problems arise. • field orders by their nature are not planned and therefore are not scheduled • field orders occur "at the last moment" during a project • field orders are dealt with immediately and then are documented at the end of the day • field orders DO NOT require lengthy deliberation by both contract parties • field orders are pre-approved • field orders ideally involve activities that have float and the extension in duration does not exceed the allowable float • field orders are non-monetary or involve very little extra cost. Any extra cost is usually not an issue. • field orders can be rolled up into an extra work order if costs increase or a change order if approval exists • field orders are also referred to as site instructions and are given by the architect and can be tracked as a change order or EWO if the need arises. 90 6.2 Extra Work Order (EWO) • for the contractor as a internal tracking of extra work above original contract, i.e. this work has yet to be approved by both sides of the contract; it provides a channel through which change orders are attached to activities and pay items (this concept may change). • extra work orders are initiated by the general contractor • extra work orders are higher level orders than field orders • extra work orders can evolve into a change order when approved • extra work orders may never be approved • extra work orders could result in a claim • extra work orders may be cancelled 6.3 Contemplated Change Order (CCO) • initiated by the client to notify the contractor to expect a change in time, cost, scope • contemplated change orders are initiated by the client • contemplated change orders are the ideal course of action • contemplated change orders will evolve into an change order or may not, i.e. cancelled • contemplated change orders are a precursor to change orders Change Order (CO) • the actual agreed upon change to the original schedule. It can originate from a series of extra work orders and/or field orders. Also, as per The Ministry standards, it can involve additions and changes to pay items, as well as force account work. • change orders can be initiated directly • change orders may have come from previous FO and/or EWO Subcontract Change Order (SCO) • the proportion of a change order that is attributable to a particular sub-trade • subcontract change orders will be linked through responsibility codes • subcontract change orders cannot exist by themselves After a strict set of definitions is adopted, the next issue to broach is the concept of amalgamating existing scope changes into new orders or into another pre-existing order. We want to be able to roll several lower level orders into one higher level one, or to roll existing lower level orders into an existing higher level order. For example an existing FO rolled into an existing CO. These composites could include the following circumstances • combine one or many CCO's into one new or pre-existing CO • combine one or many EWO's into one new or pre-existing CO • combine one or many FO's into one new or pre-existing CO • combine one or many FO's into one new or pre -existing EWO 92 Under what circumstances do we roll up lower level orders ~ What's involved ? The possibilities that exist are two or more FO's can be rolled up, two or more EWO's can be rolled up or a combination of both can be rolled up into one EWO or one CO. The new EWO or CO can be a totally new order or an existing order. When some orders are rolled up, is this a new type of change order, i.e. an integrated change order that has more documentation (containing previously defined lower level orders)? For example CO No. 123456 contains EWO Nos. 98766, 34567 & 13579. The constraints and relationships we must consider include • an EWO can belong to one and only one CO • a CO may contain one or many EWO's • an activity may be attached to one or many EWO's? When would the situation of having an activity associated to more than one EWO arise? • an EWO may contain many activities • a pay item may be associated with one or many EWO's • an EWO or CO may have one or many pay items associated with it. When a change in the project scope is initiated, the creation of a change order object can result in a variety of altered conditions or new circumstances. These consequences can include • deletion of one or more activities and or pay items • change of logic of activities • addition of activities and or pay items 93 • increment (decrement) in cost and or time of activity • change in responsibility of one or more activities • change of associations among the activities and pay items Once a change in scope is instigated, it will evolve according to one of several plots. Although there is no right or wrong unfolding of a scope change process, the following tries to identify the major or most likely scenarios. Scenario 1: The Classic Case A change is identified by the architect (client). A CCO is issued to the GC. The GC seeks pricing and time estimates from the subtrades. The GC puts a package together and submits this to the client. The client may issue a CO, cancel the CCO or ask for new estimates (negotiation and modification). Finally, a number of SCO's could result. Scenario 2: The Direct Case No CCO is issued, instead a CO is directly issued to the GC from the client. Again, there may be a number of resulting SCO's. Scenario 3: The Reverse Case The GC detects what he/she believes to be a change. He/she opens an EWO or several EWO's (depending on the number of subtrades involved). He/she hopes that the EWO or several EWO's will be rolled up into a CO. The GC could track costs through the pay item structure, making additions if necessary. If a CO is issued the CO number 94 will be associated with the relevant activities. However, if a CO is not issued a claim may result, or he may cancel the EWO. Scenario 4: A CO/EWO Hybrid A CO may be issued after the GC has initiated a change and several of his EWOs are rolled into the CO that has been issued. The GC may still want to try for another CO to cover his outstanding EWO's. We must address the issue of using only the EWO field as the channel for all changes, which is what is currently done in REPCON. Why would a contractor or client for that matter ever track changes through an EWO number if the change has originated in the classic form, i.e. an change issued directly from the architect (client)? It does not seem logical to "step back" and document the change through EWO numbers if the change has been agreed upon. It does not seem intuitive enough to channel all changes through a EWO, especially when the change is agreed upon from the beginning. Therefore it would be advantageous to include a CO field for the activity object. However, if the general contractor is initiating some change, then the EWO would definitely be the vehicle for the change order. It is in this scenario that several EWOs could be rolled up into one CO. For this rollup concept any activity that had an EWO number associated with it would also have CO number. The reasoning for this is that when it comes to apportioning the change to the subcontracts, it might be advantageous to have individual EWOs for each different subtrade, i.e. open up several EWO's for the 95 various subtrades involved. Then if and when the change is approved, one CO number can be attached to all the relevant EWO's and we are still able to track different aspects (responsibilities) of a change. The SCO would be tracked through EWO and responsibility codes. The Change Order Object Currently on the Activity screen in REPCON there is a EWO field and on the Pay Item screen there is a C/WO field already present. The C/WO (this is short for Change/Work Order) needs to be altered into a EWO or CO field. The association should come through the activities. When a change is initiated a separate line item should be entered and all additional and incremental costs should be entered here in subsequent line items, i.e. 1.0 - Change Order Number 1224, 1.1 - new doors addition cost, 1.2 - new hinges additional costs etc. It would be beneficial to include (add) a field to the activity screen that would indicate that the activity is associated with a CO. If, for a particular activity, it originally was associated with an EWO it could also be associated with a CO. A benefit to this would be if several EWO were being rolled up, the left over activities that are associated with EWO's that were not included could be left as is. In other words, if Act. 1, 2 and 3 are associated with EWO 1 and Act. 4, 5 and 6 are associated with EWO 2 then when CO 1 is issued and includes Act. 1,3,4 and 6 these activities will also have a CO number associated with them. By doing it this way the GC can track those activities which do not have a CO number associated with them and therefore he has not been paid for. Therefore 96 the GC could keep an EWO open if he still wished to claim at a later date. If the EWO number were the only channel to link CO's to activities then if one EWO contains too many activities for an issued CO, difficulties will arise. Also by including two fields (EWO and CO) if a CCO or CO is issued the client does not have to bother himself with identifying any kind of other order, namely a EWO. He can simply track the changes through the CO number. Similarly, the GC can track a change directly through a CO number if he has not already identified the change. Checks must be made in reporting and listing that if an activity is included in a CO then it must not be included in a EWO. Entering/Changing Activities and Pay Items Added, changed or deleted activities and/or pay items should be entered or corrected through their respective routine prior to documenting the change order in the Change Order routine. This will be necessary to simplify the documenting process. Other Issues The Field Order This term could also be referred to as Site Instruction. In an ideal situation, if a field order or site instruction were given by the architect (client) it is pre-approved and should not become an issue. Therefore it could simply be handled in the Daily Site report or noted somewhere in the change order management section so that it is documented. 97 However, if a field order or site instruction is issued (usually orally), the GC has the option if he is worried to open an extra work order and start tracking the change though this number. Special mention should be made reflecting that this EWO was originated by a site instruction. Then if problems arise he can hope to have a CO issued or he can claim. The possibility could also exist that the EWO be cancelled. The Contemplated Change Order Since the contemplated change order is a precursor to the change order, possibly we will want to handle the CCO as a CO with the status of CONTEMPLATED. The benefit of this would be the ease with which the CCO could be upgraded to a CO. By simply changing the status of the CO it could become active. Implicit in this idea is that if some manner of reporting is being done on change orders, any CO with a status of CONTEMPLATED will not be included, or reported on as such. The Subcontract Change Order Since this is a subset of a change order or extra work order, it does not necessitate its own numbering system. The GC would have the option of opening a separate EWO for each separate subtrade, or alternatively he could define a report by responsibility code, thereby breaking the change down into subtrade changes. The System Structure 98 It is becoming apparent that the concept of capturing the change order process in a "general" form for utilization in a computerized system presents an interesting situation. The design of this component of construction management is intriguing yet difficult to get a full grasp on. However, having said that, this iteration of this document will try to present a routine to handle the change order management in REPCON. To begin, the structure used to handle the pay items can be used as a framework to develop the change order routine. This hierarchical configuration lends itself more than adequately to the "ideal" change order process. By implementing this organization a more direct route to the change information can be achieved. Before the actual structure is presented, it will be necessary to provide a list of all the pertinent attributes belonging to the change order object. The following listed characteristics represent the necessary attributes, but the list is not solely restricted to these. • a number internal to REPCON (for internal tracking) • a number external to REPCON (outside documentation number) • various dates: • date of issue • date of approval by owner • date of approval by GC • date of change of status 99 • reference name(s) • associations with activities • associations with pay items • responsibilities • status • scope (details) • description of change order history (e.g. to include any rollup details) • associations with records and with physical view Chapter 4: Implementation and Field Experience 4.1 Site Trial Data Results Early in 1996, sufficient prograrnming of enhanced REPCON features as described in the previous chapter had been completed in order for data to be entered. As stated earlier, data was collected for the month of November and it was this data that was used to test REPCON's features. Included in the data collected were all the available daily site reports for November, all pay item progress amounts up to end of November, all supplemental agreements for extra work up to the end of November, a selection of quality test reports, and other miscellaneous records. To augment this set of data, a series of digital photos were taken at the job site to further test the Records routine. The schedule generated from REPCON that was adapted from the contractor schedule is presented in Figure 4.1, and it was used as the base against which documentation in the Daily Site system was associated. Since this schedule is merely a three month schedule from a much longer project duration, the activities shown to be critical are not necessarily so. Predecessors prior to this schedule and successors subsequent to this schedule were not considered and hence the issue of the critical activities becomes suspect. 101 z o u a UJ c < j H Z 111 2 lit O < z < z z • o M H u D a. i -i n z o u u m D 0 • L a 01 c > o X 5 io a: cc a. c 10 r 01 51 c L ro III L 0 5 O a. U J S3 s s °-to oj o • 0 a. hi m 3L UJ U hi a a oj ca S ^ 01 UJ 01 > o z cc LU CQ O I-u o s in 8 CT1 LD i i § ° 10 s • i 1 s s 1 S 9 £ O O O S S 55 g s a> 3 a O O Q Figure 4.1: The Test Project 3 Month Schedule from REPCON The following section will address several specific views of project management and how each relates to the test project. Special emphasis will be given to the Pay Item, Daily Site and Records views that serve as the prevailing views for current Ministry concerns. Although not all the facilities of REPCON could be properly examined with the month of test data, comments will be presented on the relevant views and future work and improvements will be discussed in the succeeding chapter of this thesis. 4.2 Pay Item View The reporting features, explained in Chapter 3 of this thesis, better respond to the needs of the Ministry. They are now able to produce reports similar to the ones they currently generate. The added benefit from the REPCON approach is that a full list of all pay items is 15 pages compared to the 40 pages of the Ministry's program's report. Added to this aspect is the fact that the Ministry system of progress measurements of pay items involves a rough copy of all pay item progress (29 pages), a reconciled report (29 pages), and the final copy from TEPE (40 pages). An auxiliary feature of REPCON is the ability to only report on a desired set of pay item or all the pay items. The Ministry report groups all pay items together. This REPCON feature allows a user to select relevant pay items in order to make comparisons with other sets of pay items if so desired. The pay item progress measurements data from the test project, to the end of November 1995, were entered into the Pay Item routine in REPCON. Because only one month of data was collected to analyze REPCON's capabilities, all pay item progress 103 completed prior to November 01, 1995 was input as one entry into the system. Therefore what appears as October's progress payment is actually all pay item progress from the onset of the project. However, the values cited as November's amounts are indeed November's true measurements. Figure 4.2 is an example of REPCON's print out for November's progress payment, while Figure 4.3 is The Ministry's corresponding report. Presented in Figure 4.4 is a page from REPCON's progress for October and November. Although only single pages from the reports are presented here because of confidentiality, the monthly totals from REPCON are correct (not shown). 104 Wl 3 2 co 55 S S ¥ s s s w 3 S S K !2 S (— cr. m rsj ^ ^ ^ r-j CD LTl LSI OO CC] CO LT> CP* QD v ro c£2 cj^  r*— ro co SP ^ ^ °° ^ ^ in # ft H | | | 5 " W !« s » £ S g § | LO co .c J C _C O U U CJ CJ co co co CP 5 E to =3 1 3 27.28 52.28 7.88 1.88 1.88 1.88 9.B8 s H H m £ £ £ m 1 I 1 £ £ £ £ I 11 I I I J i l l 1 1 11 1 I 1 1 I 1 I 1 1 •J3 v£l i_o LO U3 LO CD Lfl CD Ifl U3 LO CO r3 LO 13 J SI It 1 = E E 3^  01 (/l W — !3 53 8 £ —. D O =. J S Kl LO as a. a a 0 Is 1 1 3 CJ c5 r>4 ro rsj pg LO u-» to "itj to — m • s . EC U u CJ u u <3 <3 e5 5 (3 «J « «s * w S S « S S 5 E E E E " S S i i^ W « * >W « ~ O "S. S S S S S S .2 « a 5 I" 3 f J J 8 •= g 3 CO CD CO CD ^ E Z> •I .? •3 •- o ' • 3 8 I 4-1 i2 * - - - " & " » D D 1 = t a i a < s o s i i i f - B 3 = S C C C C *-* V C Q C D C E C O Z > E Z > : * J C 5 ^ 3 6 55 3 a LO LO Figure 4.2: A Page from REPCON's Pay Item Progress Report for November, 1995 105 a a Q . HI h -< I— CO LU CO CO LU CC C9 o CL xi E o O sz > o 1_ a. Z (0 D UJ O co LLI Z I-D < O Q < i -LU 2 3 I S LU 3 O a O r> 8 8 CL co C L co CL CO C L CO < CO 3 (SP Finish 4.3.3) CO ectu 2) Q_ CO_ Archi' 3.4.6. Instal C L CO C L co CL CO < co' Figure 4.3: A Page from The Ministry's Pay Item Progress Report for November, 1995 106 s l KIC i f m § 1 Lit L/i ci ci v£ 3 CD* CD* c§ CD 88 s i s l 22 g g c i in ro S $5 "5 "S "5 if! K S g 31 co c i rsj 3 3 3 a a a iZ LC 1 J cn r-co c=» I 1 — t/l HI •S. J J3 ^ "i - s . - s . - s . s - s . - s . s - s . - s . cu OJ to cu to cu cu -0 -O -T3 ITJ -T3 T3 rtj T3 T3 ma nt m tn • e c u oj J cu c u e u OJ cu -3 c5 ^ *. ^ ^ (g y * ' ^ .2 *° "° "° . 2 " ° "° .2 S3 P S ™ CD CD CD CD CD CD * J g ci f N r-i r-i £r-> ci E (si ci r»J rsJ "W g eg r-J • g CD r~j ,-s. cj^  rM ,<\ L£> CD ro w r « 4 r n _ 4 i - s J . > - i . r s l »-i .-1 N N cvi rsj ci ci ci Figure 4.4: A Page from REPCON's Pay Item Progress Report for October and November, 1995 4.3 Daily Site View The daily site data from the test period was entered through REPCON's Daily Site feature in order to verify the validity of the various reports available to the user. This task took a great deal of effort to properly assign the given activity data to the scheduled activities presented on the system schedule. Unfortunately, the schedule as it was completed by the contractor was not as accurate as one would anticipate. To confuse this situation, The Ministry staff does not log the daily site activities according to the actual activity names given in the schedule. The staff is more likely to comment on the events that are occurring on the job site and describe them with respect to where they are transpiring and who and what are involved with the event. For example, a staff member recorded that on November 01, 1995 at right hand side of Station 70 a Komatsu excavator was being used by a 4-5 man pipe crew. Together they were installing perforated subdrain in a ditch with cloth and drain rock. This "activity" does not appear on the contractor's schedule for that particular day, nor does it fit into any activity on any day. This situation demonstrates another problem: The Ministry is interested in what is actually occurring on the job, not in what is forecast to happen. At any rate, the bulk of the daily site data was entered under the scheduled activities, while questionable data (with respect to given activities) was recorded under separate sections of the Daily Site feature, such as miscellaneous notes or daily equipment. Figure 4.5 is an example of a Daily Site report generated from REPCON and the corresponding Daily Site report from The Ministry is shown in Figure 4.6. 108 3 I I Figure 4.5: Daily Site Report Generated from REPCON 109 _r . BARNEJJjWY. 09052 P R O J E C T : _ C O N T R A C T NO: C O N T R A C T O R : BAJBLACKTDP R E P O R T N O : ^ D A T E : I N S P E C T O R : r->. " j T i s o r v up. AM._ I'M.. J - / O . C W e a t h e r ' PM B A I l J MANPOWi:iVl7-ODIPMEMT IN USE/ACTIVITY I'AY 11 EM STA. 10 STA. 3 Q < c O - P,c» 2 0 e -ea<?<a..-.,xy<a£2 tr ACTIVITIES _ 8 6 > - . < B S . . - . . 3 ^ P O * - T ,pO- 9 '*oo tjr 9&*t<9_ -86JCO-8 8 ->oo-bO 8 S - . 0 0 - 9ftOO LT <--[ APP£Ami.>t. S ^ R / A J TOUT «- reg-g/Ain M J A ^ < : S - 9&* o o *-r Fim£4/OG CJp vjrrit i-Oig'SV: £ - / * J F njcigurq - n p A A j S P o g r ' A J C * P A C T S T O ^•/rg' P A ^ i i ; A J T O ptAC/c- F o e w < t t . 5 r~>K)£e?>£G,'>J0r c o ^ J K r p i i o v t v j n P vAj>v^d ?; &al3£*i<?X>ti<2.. SCrSfj t/-7ABr MAOUrlb. 1>(,S&. ro a A I C V A J 2 U i ^ M A A J . , _ S < t £ , S /. - 7Aie ' _ . 5 V 6 S S C £ / A J A J A O i - *V/oUJ [ T : A ? A F F A C g^>unFOt. F o r e >f=A»S T U W » ) 6 O Q J - Q ' - /g ' « k ^ ? F A A C . P ^ g ^ . O ' > ; H A O M A J C T S 6 - S . R T o n / ( L J L . 7 A S _ EQUIP/MNPWR 3 2 g Z. Aitog •4-i ^ S Q G, C A T C A T T A O Q g r t S EXTRA WORK I v/ll ll». Il.iw .. l ion| l . ( |uipnenl_l l rs |- |" l ll' o w e r l i d HAUL Material Cut s:/s Fill S/S Vot/LC visimu:: mi SUE QUALITY ASSURANCE P.S. SIGNATURE i^P. S I C M A T U R E / Q ~ / 4 ^ Z . Figure 4.6: Corresponding Ministry Daily Site Report 110 The sole report The Ministry possesses concerning the daily site data collected is the actual Daily Site report. Conversely, REPCON is decidedly unprecedented regarding report generation. The ability now exists for the user to formulate reports on particular topics of interest without having to cull tedious bits of information from countless forms. He/she now can choose an applicable report, stipulate the time window and print out the data in very short time. The various details of the reports were introduced in Chapter 3 and subsequent figures illustrate several of the relevant reports for November's data. Figures 4.7 through 4.11 are, respectively, a Work Environment report, a Work Force report, a Deliveries report, an Equipment/Rentals report, and a Miscellaneous Notes report. Notice that on Figure 4.9 there is no quantity noted in this report. No quantities were reported only that deliveries were made. The report is included to demonstrate its availability. The remaining reports, although capable of displaying their pertinent data, are not included as the extent of November's data proved to be insufficient for these reports. However, extensive testing was performed on them with mock data to affirm their ability. Finally, the Report Generator described in Chapter 3 strengthens the user's ability to compose report documentation and Figure 4.12 is an example of a report generated using this feature. Note the wrap around feature of this modification, resulting from the numerous options selected. The total length of the document is 58 pages; however, Figure 4.12 presents only one page as the example. Notwithstanding this wrap around effect, the Report Generator is a powerful tool for the user of the system to customize reports for explicit needs. I l l z o u n. w erf ft) y j : cc cw cc O PL. a a LD O i— m '—^  i— — CD en- — Si"12 K g g ' 5 = CO dt gar? 11JJ M ^ W w p a ) o o a o o CXX X X X X X X X XX XXX X) X X X X X X XX x » XXX X X X X X X XX XXX XX -< H z w 2 w o •< 2 <• s z o H o p eS H CO z o o o CQ o < a as £S3 Ha C3m u = • £ . 8 • Ck. /O £ £ 3 5 a i a m CD ca c CD CO CD CD CO CD CD co c 3 CO CD CO CO i 8 c 2 -3 C LO un C X X X X X X X X £ • 2 -S B Figure 4.7: A Work Environment Report 112 Figure 4.8: A Work Force Report r, o o w d *j *J OJ • — t_ t_ t_ t*o O O en-— Q. Q. O =» cc cc a. cc Figure 4.9: A Deliveries Report 114 JZ I l l s . •— O 31 C CX3 C d C CO "cf OJ c n S . t ! " ~ ai a a * ""* . '-c 8 OJ 35 3s 35 S "3 3 C> — O- cx-kJ h.3 s s s s s s s s s s s ss § § s § S S S S S S S S 3 S S SSSSSSS S S S 5 5 SS S 5 S 5 sansung hoe Konabu exc cat 968 JD 658 dozer Cat Packer grader Cat 968 loader Case 588SK JD 658G 588 SK Cat 966 Case Back hoe 586 K Case Rubber Tired Back Moe JD grader tandens Cat CSS53 Packer Cat 958 F Sansung SE 288 LC Cat Back Hoe worktruck Cat 958 F Boontruck Cat 958 F tandens Cat 958 F 235 D Hoe truck and transfer 956 F front end loader 288 Hitachi Hoe 235 D Hoe tandens JD 118 Case 59B 1 Iff 1 I III | | | | | | | | Iflllllftlf Iftlllf i i 1 ii. 11 l 11 i i Figure 4.10: An Equipement/Rentals Report 115 o Figure 4.11: A Miscellaneous Notes Reports 116 117 4.4 Records View A small subset of Ministry records were used to test the Records routine in REPCON. None of the records were scanned in and used. Rather, the associations of the records to other pieces of data and the reporting of it was of preeminent importance. However, a digital camera was used to capture some pictures of elements of the job site. These images do not require scanning as they exist in digital form from the onset, thereby, allowing the user to view them through the image display software available through REPCON. Figures 4.13 through 4.14 demonstrate records reports that are feasible to produce; however, many possibilities exist. Again, it is important to reiterate the fact that the records report generator is only as useful as the level of effort that was initially used to establish the diverse links among project data. 118 2 O O W' Figure 4.13: An Example of a Records Report 119 ASSOCIATE PAY ITEMS/ACCOUNTS CODE DESCRIPTION MAGE FILE D: \BRETT\BARNETrU\HYDRANT. JPG STORAGE LOCATION original d ig i ta l inage REMARKS RECORD CODE IPH-B8S DESCRIPTION waternain drain DATE 23N0V9S ASSOCIATE ACTIVITIES CODE DESCRIPTION B1B5BB Instal l Uaternain 66*E to 79-ASSOCIATE LOCATIONS NAME DESCRIPTION ASSOCIATE PROBLEMS CODE DESCRIPTION ASSOCIATE PAY ITEMS/ACCOUNTS CODE DESCRIPTION MAGE FILE D:\DRETT\BARNETW\DRAIN.JPG STORAGE LOCATION REMARKS RECORD CODE lffl-887 DESCRIPTION wall 3 top edge view DATE 38NOV9S ASSOCIATE ACTIVITIES CODE DESCRIPTION Retaining Ual l 13 ASSOCIATE LOCATIONS NAME DESCRIPTION 8B98 Sta B8-88 to 98 ASSOCIATE PROBLEMS CODE DESCRIPTION ASSOCIATE PAY ITEMS/ACCOUNTS CODE DESCRIPTION 3.1 Structure Backf i l l S.G.S.B. s h p c 3.Z.1 Uall 13 Supplu (SP Architectural F in ish (SP Instal l (SP l i r a FILE D:\BRETT\BARNETHW\UAL3-T0P.JPG STORAGE LOCATION or iginal d ig i ta l inage REMARKS RECORD CODE IPH-B88 DESCRIPTION close up view of reco block DATE 38N0U9S: ASSOCIATE ACTIVITIES CODE DESCRIPTION Retaining Ual l 13 ASSOCIATE LOCATIONS NAME DESCRIPTION BB98 Sta 88-88 to 38'! ASSOCIATE PROBLEMS CODE DESCRIPTION ASSOCIATE PAY ITEMS/ACCOUNTS CODE DESCRIPTION 1.1 Structure Backf i l l S.G.S.B. s h p c 1.2.1 Uall 13 Supply (SP Architectural F in ish (SP Instal l (SP l i r a FILE D:\BRETT\BARNETHARECOBLCK STORAGE LOCATION original d ig i ta l inage REMARKS RECORD CODE. IPH-689 • DESCRIPTION reco wall 3 DATE 38N0U9S ASSOCIATE ACTIVITIES CODE DESCRIPTION Retaining Ual l «3 ASSOCIATE LOCATIONS NAME DESCRIPTION B89B Sta 8B*B8 to 98 ASSOCIATE PROBLEMS CODE DESCRIPTION ASSOCIATE PAY ITEMS/ACCOUNTS CODE DESCRIPTION IMAGE FILE Figure 4.14: An Example of a Records Report 120 4.5 Quality View The programming for the reformed quality management view remains to be done. After substantial consideration it was decided that because of the importance of proper quality management more time needs to be spent on structuring such a system. What came out of this work was the appreciation of the fact that current quality management feature in REPCON is too restrictive. The Ministry's paradigm of quality management, although ideally matched to the pay item structure, is not adhered to strictly and the prime facie organization of it neglects the hierarchical structure. It is unclear as to how The Ministry exploits their immense collection of quality reports. Regardless, REPCON, too, contains no tool to survey test results and apply or incorporate that knowledge to a project at hand. 4.6 Change Order View Previously, this thesis endeavored to state some Change Order management theory. This effort was purely conceptual and no attempt at programming was undertaken. The Ministry's current change order management is viewed as being satisfactory by Ministry staff. If a contractor wishes to submit an extra work order, he/she does so with the form shown in Figure 2.8. The Ministry project supervisor reviews the request and if any or all of it is accepted, and a Supplemental Agreement is issued. These supplemental agreements, as shown in Figure 2.9, are treated as individual pay items at the end of a progress report. Project 9052, as of November, 1995 had incurred only nine such agreements. Payments are made according to the type of work completed. In some 121 instances payments for agreement can continue for several months, while others are simply completed in one lump sum. 122 Chapter 5: Technology and the Future 5.1 The Digital Camera As information technologies propagate the need for "hard" forms of documents decreases; the same is true for visual pictures as well. In support of this thesis a fair amount of time was devoted to acquiring and analyzing Kodak's Digital Camera, model 40. This simple to operate camera can store up to 48 images at one time. These images are then downloaded into a PC where they can next be viewed on screen or stored for future use. The on-screen quality of the images is quite remarkable for visual site documentation. Since they can be downloaded and viewed immediately after the pictures are taken, the lapse in time for conventional development is eliminated. The images can easily and quickly be incorporated into the documentation system without loosing knowledge of circumstances of the photos. The software that comes with the camera also allows the images to be printed out on a laser printer. The quality of the printed image is adequate for incorporation into documents. Figure 5.1 is an example of a printed digital image. Since the images can be stored in several data formats, they can be easily employed in a diverse number of applications, including word processors. The capability now exists, as an example, to compose a report regarding a problem on the job site, document it with actual pictures and fax it to another office where a decision can be rendered, and completing this process quickly and efficiently so as to minimize lost time. 123 Figure 5.1: An Example of a Digital Camera Image 5.2 Exporting and Importing Data With the potential for a vast body of data available in REPCON, the concept of exporting data to and importing from other systems must be entertained. The ability to export data reports to word processors, as an example, for inclusion in summaries or in final accounts is of marked importance. Consideration also needs to be given to the importing and exporting of pay item information given The Ministry's penchant for using spreadsheets. 124 As technology flourishes, the requirement for paper is diminished and thought needs to be given to data acquisition methods. No longer will it be necessary to record progress or circumstances first on paper forms for later entry into a computer system. Conversely, hand held units for logging data will become commonplace and computer systems will be expected to automatically incorporate new data to the relevant routines. Similarly, scanning of records, which is currently the method employed to bring documentation on-line in REPCON, save the digital camera, will become obsolete as new methods of aggregating data digitally from original sources increase. Resulting from the advances that eliminate the printed form of documentation is an increased volume of computer files from the actual construction management software and the peripheral associated records. Complete as-built digital records of construction have the potential to be hundreds of megabytes in size, and CD-ROM technology responds to this situation. Current advancements allow users to store thousands of gigabytes on compact discs with available software and hardware. Suddenly, an entire project's documentation can be stored on one compact disc, severely reducing the need for physical storage space for the massive amounts of paper forms generated using the traditional process. 5.3 Programming Wants Regardless of the accomplishments fulfilled in this thesis, the inventory of further improvements grows with each completed task. Report generation was a major 125 achievement; however, expanded capability for report generation is still desired. To begin, added fields of data need to be added to the Daily Site routine report generator. This advantageous feature will become even more powerful for individually structured reports with the inclusion of many of the Daily Site data reporting fields currently unavailable. As well, to combat the Report Generator's wrap around idiosyncrasy, consideration must be given to producing reports on larger paper: 8.5 x 14 as opposed to the standard 8.5x11. As special needs of project managers arise, a report generator could be configured for his/her specific requirements, thereby making reporting more efficient. Composite with this idea is the concept of a premium report generator that could be used to select the type and number of individual reports that a user wished printed out. In other words, once a user has decided which reports he/she would like produced, he/she could utilize a master report generator that would sequentially produce the desired reports and amalgamate them into one integral report. Other future improvements relating to user-friendliness merit consideration also. Accoutrements such as templates for the first time user could be employed to expedite project start up. By prompting the user along, the question of how to proceed initially can be lessened and time consuming mistakes can be avoided. Again, to expedite project start-up, a series of standard projects or templates (e.g. quality, pay item, etc) could be adopted. Although this would be an immense task of agglomerating large amounts of 126 data, the end result would be project management that could learn from past mistakes and improvements. Finally, serious consideration needs to be given to quality management and change order management as outlined in this thesis. These topics are of major concern and magnitude, and therefore warrant a substantial amount of thoroughness. It is the hope that future work on the construction management system, REPCON, will incorporate many of the previously mentioned enhancements, and again build on current ideas and theories. 127 Chapter 6: Conclusions and Recommendations This iteration of REPCON dealing with the needs if a public owner successfully adapted several new or modified feature. They include: • Pay Item progress payments possible outside of activity associations, including summary reporting for month end payments • Pay Item and Records associations possible through the Pay Item routine • Activities and Records associations possible through the Activities routine • Modifications to the Daily Site routine including a compliment of Reporting features • Records routine modifications for associations and selecting and sorting features • Programming outlines for future work for a Quality Management routine and a Change (Scope) Order Management routine This thesis increment represents the latest endeavor to address The Ministry's construction management needs as a public owner, and thus help demonstrate to the Ministry some of the opportunities and benefits information technologies offer. The advances achieved through this thesis more acutely respond to the immediate realities the Ministry has. Through the improved Daily Site feature staff are now able to produce a wide range of reports to reduce the requirement to search countless forms for relevant data. The as-built views that can now be produced exemplify a construct from which 128 lessons can be learned and innovations can be applied to subsequent projects. In essence the Ministry has captured data to use on future projects. Yet, as with all software development and adoption, there remains unresolved issues. The most significant of these is The Ministry's predisposition to not be schedule driven, and this is not to imply that they are unable to function without a schedule. Rather the conclusion is one to suggest that a great benefit can be achieved by establishing a schedule to align a project and create a baseline for project monitoring. However, this issue is compounded by the actual scheduling of activities: to what degree of detail should a schedule be produced? Nevertheless, the ultimate fact is that more effort put into a schedule from the onset will greatly reduce the onus on the user filling out a daily site form. As stated formerly, a more comprehensive quality management routine will need to be developed. The question of proper quality data organization and retrieval is an immense topic and deserves a thorough approach. This must include, from The Ministry, their conception of what they want to achieve with advanced quality management. The actual adoption of this system will require a great commitment by The Ministry and its personnel. Because one person cannot alone run the system, many people must be trained in its use and that also implies modified thinking as well. Although the REPCON advancements were designed to model existing Ministry procedures, a 129 Finally, an extensive validation exercise to assay all features and conditions of REPCON is required. Ultimately the question of whether or not REPCON can be adopted will rest with the personnel of The Ministry and their attempt to "try" out the system on a test project. This would involve simultaneous documentation of the project in both the traditional method and the computerized technique. Technology is inevitable and the Ministry can exceedingly benefit from embracing it and accepting its differences and betterments. 130 Bibliography Abudayyeh, Osama. "Image Databases in Construction Management," Computing in Civil Engineering: Proceeding from the Second Congress, Vol. 2, Atlanta, GA, June 1995, 1302-1307. Abudayyeh, Osama. "Partnering: A Team Building Approach to Quality Construction Management," Journal of Management in Engineering, Vol. 10, No. 6, November/December, 1995, 26-29. Chin, S., Liu, L., Stumpf, L., Ganeshan, R, Hicks, D. "CADD-Based Construction Information Management for Corps of Engineers Projects," Computing in Civil Engineering: Proceeding from the Second Congress, Vol. 2, Atlanta, GA, June 1995, 187-194. Cleveland, A., Skolnick, J. "Database Integration in Support of Construction Management," Computing in Civil Engineering: Proceedings from the First Congress, Vol. 2, Washington, D.C, June, 1994, 2054-2057 . Coble, Richard, J. "Expanding Pen Computing Capabilities to Include More Effective Field Applications," Computing in Civil Engineering: Proceeding from the Second Congress, Vol. 2, Atlanta, GA, June 1995, 1340-1343 Cohen, Stanley. "Designs: They Are A-Changin'," 1992 AACE Transactions, E l . 1-E1.6. East, W., Kim, S. "Standardizing Schedule Data Exchange," Journal of Construction Engineering and Management, Vol. 119, No. 2, June, 1993, 215-225. Ehrenreich-Hansen, Fritz. "Change Order Management for Construction Projects," Cost Engineering, Vol. 36, No. 3, March, 1994, 25-28. English, Ralph. " Computerized Site Documentation of Public Sector Construction Projects," Master of Applied Science Thesis, University of British Columbia, Spring, 1995. Ganeshan, R, Kim, S., Liu, L., Stumpf, A. "A Multi-Media System for Organizing Construction Documents," Computing in Civil Engineering: Proceedings from the First Congress, Vol. 2, Washington, D.C, June, 1994, 1381-1388. Ioannou, A., Liu, L. "Advanced Construction Technology System," Computing in Civil and Building Engineering: Prceedings from the Fifth International Conference, Vol. 1, Anaheim, CA, June, 1993, 161-168. 131 Jazayeri, Jason. "Using Computer Program To Develop As-Built Schedules," Computing in Civil Engineering: Proceedings from the First Congress, Vol. 1, Washington, D.C., June, 1994, 191-196. Jergeas, G., Hartman, F. "Contractors' Construction-Claims Avoidance," Journal of Construction Engineering and Management, Vol. 120, No. 3, September, 1994, 553-560. Knoke, John. "Avoiding Delay Claims with Automated Schedule Reviews," Computing in Civil Engineering: Proceeding from the Second Congress, Vol. 2, Atlanta, GA, June 1995, 1506-1512. Knoke, John. "Computer Use in Claims Analysis ~ Roundtable Discussion," Computing in Civil Engineering: Proceedings from the First Congress, Vol. 2, Washington, D.C., June, 1994, 2136-2139. Knoke, J., Spittler, J. "Direct Range Estimating for Change Orders," 1990 AACE Transaction, M. 3.1 -M. 3.1' 1. Liu, Liang. "Digital Data-Collection Device for Construction Site Documentation," Computing in Civil Engineering: Proceeding from the Second Congress, Vol. 2, Atlanta, GA, June 1995, 1287-1293. Liu, L., Stumpf, A , Chin, S., Ganeshan, R., Hicks, D. "Construction Daily Log Management System Using Multimedia Technology," Computing in Civil Engineering: Proceeding from the Second Congress, Vol. 2, Atlanta, GA, June 1995, 1084-1089. Liu, L., Stumpf, A., Kim, A. "Applying Multimedia Technology to Project Control," Computing in Civil Engineering: Proceedings from the First Congress, Vol. 1, Washington, D.C., June, 1994, 608-613. Liu, L., Stumpf, A., Kim, S., Zbinden, F. "Capturing As-Built Project Information for Facility Management," Computing in Civil Engineering: Proceedings from the First Congress, Vol. 1, Washington, D.C., June, 1994, 614-621. Riley, M., Pickering, C. "A New Automated System of Decision Support in the Construction Industry," Computing in Civil Engineering: Proceedings from the First Congress, Vol. 1, Washington, D.C., June, 1994, 523-530. Russell, Alan, D. "Automated Interpretation of Job Site Records," Computing in Civil Engineering: Proceeding from the Second Congress, Vol. 2, Atlanta, GA, June 1995, 989-996. Songer, A., Rojas, E. "Developing a Field Inspection Reporting System for the Construction Industry," Computing in Civil Engineering: Proceeding from the Second Congress, Vo. 1, Atlanta, GA, June 1995, 123-130. 132 Thabet, W., Morad, A. "An Integrated Computer Model for Project Schedule Updating; Computing in Civil Engineering: Proceedings from the First Congress, Vol. 1, Washington, D.C., June, 1994, 743-750. 133 


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items