Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Data visualization of requests for information to support construction decision-making Bhat, Achintya Sheela 2017

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

Item Metadata

Download

Media
24-ubc_2017_may_bhat_achintyasheela.pdf [ 8.66MB ]
Metadata
JSON: 24-1.0344010.json
JSON-LD: 24-1.0344010-ld.json
RDF/XML (Pretty): 24-1.0344010-rdf.xml
RDF/JSON: 24-1.0344010-rdf.json
Turtle: 24-1.0344010-turtle.txt
N-Triples: 24-1.0344010-rdf-ntriples.txt
Original Record: 24-1.0344010-source.json
Full Text
24-1.0344010-fulltext.txt
Citation
24-1.0344010.ris

Full Text

Data Visualization of Requests for Information to Support Construction Decision-Making by Achintya Sheela Bhat B.E, Visvesvaraya Technological University, 2015  A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF  MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE AND POSTDOCTORAL STUDIES (Civil Engineering)  THE UNIVERSITY OF BRITISH COLUMBIA (Vancouver)   April 2017   ©Achintya Sheela Bhat, 2017 ii  Abstract The construction industry is dependent on effective communication among project team members. Construction data has varied formats and size, and are communicated through a variety of mediums over the course of the project. This often leads to potential discontinuity and delays in communication between project team members. Requests for Information (RFI) are the standard form of communication between the design team and the construction team. RFI’s are not just a means of construction communication; the fact that the RFI has been generated points out that there is something wrong, missing or unclear with the existing documents and designs. Past studies have suggested that RFI’s are an indicator of deficiency in design documentation. Current RFI management systems are not sufficient to provide project participants with a medium to analyze the problems, their cause or even to easily look for information required in these RFI documents. From past studies, we know that visualization helps humans to analyze complex and vast amounts of data easily. In this study, we develop visualizations of data in the RFI documents and investigate if it has potential benefits for construction project members.  To extract and transform data from the semi-structured RFI documents, we develop a framework by employing the qualitative technique of content analysis. A case study approach was employed for this study. Approximately 1,400 RFI’s were analyzed from Project A and around 500 RFI’s were analyzed from Project B.  In this framework, we identify several quantitative and qualitative dimensions including time (when), spatial context (where), actor (who), reason (why), RFI Type, Domain, Property, Attribute, Entity (what) that can be used to visualize the data for analyzing the information in the RFI’s. The RFI dashboard was developed with constant feedback from industry personnel who stated that the dashboard had promising benefits for both the consultants and the owners.  iii  The contribution of this research is the development of a framework to structure and organize the information in RFI documents, the creation of a prototype dashboard visualization of RFI data, and the assessment of the potential benefits of RFI data visualization for decision making in the construction industry.  iv  Preface For this thesis, the author had the major contribution in data analysis and developing the research approach and research outcomes. The author received continuous support and feedback from her supervisor Dr. Sheryl Staub-French and research mentor Dr. Erik A.Poirier. To develop one of the sections of this thesis research, the author received feedback from Hasan Burak Cavka and Dr. Puyan Zadeh from the UBC BIM TOPiCS lab. To validate the manual data analysis approach used for this thesis research, a section of the data collected was analyzed by Mariazel Rios Motte, from UBC BIM TOPiCS lab. A section of this thesis research has been selected to be published in a conference proceeding: Bhat, A, Poirier, E and Staub-French, S (2017) “Investigating the Potential of BIM to Address Project Delivery Issues”. CSCE International Construction Specialty Conference, Vancouver, BC, May-June 2017. The author conducted all the research and wrote most of the manuscript. The co-authors Dr. Erik Poirier and Dr. Sheryl Staub-French are the author’s research supervisors, were involved in providing guidance and reviewing the manuscript.    v  Table of Contents  Abstract .......................................................................................................................................... ii Preface ........................................................................................................................................... iv Table of Contents ...........................................................................................................................v List of Tables ............................................................................................................................... vii List of Figures ............................................................................................................................. viii List of Abbreviations .....................................................................................................................x Acknowledgements ...................................................................................................................... xi Dedication .................................................................................................................................... xii Chapter 1: Introduction ............................................................................................................... 1 Chapter 2: Background ................................................................................................................ 7 2.1 Request for Information .............................................................................................. 7 2.2 Data Visualization in Construction ........................................................................... 12 Chapter 3: Research Methodology ............................................................................................ 17 3.1 Objective ................................................................................................................... 17 3.2 Research Activities ................................................................................................... 17 3.3 Case Study ................................................................................................................ 20 Chapter 4: Findings .................................................................................................................... 32 4.1 Development of Approach to Structure RFI Data .................................................... 32 4.2 Development of Data Visualization Approach ......................................................... 72 4.3 Challenges ................................................................................................................. 93 4.4 Suggestion ................................................................................................................. 94 vi  Chapter 5: Conclusion ................................................................................................................ 98 5.1 Summary ................................................................................................................... 98 5.2 Limitations and Future Work .................................................................................... 99 Bibliography ...............................................................................................................................101  vii  List of Tables Table 2.1: Requirements for RFI Data Visualizations .................................................................. 16 Table 3.1: Project Overview and List of Data Collected .............................................................. 21 Table 3.2: List of Documents Analyzed from Project A .............................................................. 22 Table 4.1: List of RFI Types with Description ............................................................................. 46 Table 4.2: List of RFI Reason Categories with Description ......................................................... 47 Table 4.3: List of RFI Domain and Element Categories with Description ................................... 48 Table 4.4: List of RFI Property Categories with Description ....................................................... 49 Table 4.5: Kappa Value for Different Categories of Coding ........................................................ 63  viii  List of Figures Figure 2.1: List of RFI Type and Reason Categorization from Previous Studies .......................... 9 Figure 3.1: Research Roadmap Showing the Relationship of All Objectives, Research Activities and Sub Processes ......................................................................................................................... 19 Figure 3.2: Flow of Communication Documents for an Issue Between Project Participants....... 25 Figure 3.3: RFI Workflow for Project .......................................................................................... 26 Figure 3.4: Snapshot of RFI Template from Project A ................................................................. 28 Figure 3.5: Snapshot of CC Template from Project A.................................................................. 29 Figure 3.6: RFI Workflow in Project B ........................................................................................ 31 Figure 4.1: Structure of RFI Document ........................................................................................ 34 Figure 4.2: Coding Strategy .......................................................................................................... 35 Figure 4.3: Flowchart of Coding Process for Type and Reason Category ................................... 38 Figure 4.4: Flowchart of Coding Process for Domain Category .................................................. 42 Figure 4.5: Proposed Framework to Structure RFI Data .............................................................. 44 Figure 4.6: RFI Coding Example 1.1 from Project A ................................................................... 50 Figure 4.7: RFI Coding Example 1.2 from Project A ................................................................... 51 Figure 4.8: RFI Coding Example 1.3 from Project A ................................................................... 52 Figure 4.9: RFI Coding Example 1.4 from Project A ................................................................... 53 Figure 4.10: RFI Coding Example 1.5 from Project A ................................................................. 54 Figure 4.11: Snapshot for Example 1 of the Model Before Revision ........................................... 57 Figure 4.12: Snapshot for Example 1 of the Model After Revision ............................................. 58 Figure 4.13: Snapshot for Example 2 of the Model Before Revision ........................................... 60 ix  Figure 4.14: Snapshot for Example 2 of the Model After Revision ............................................. 60 Figure 4.15: Sample Chart for Contingency Table ....................................................................... 62 Figure 4.16: RFI Coding Example 2.1 from Project B ................................................................. 65 Figure 4.17: RFI Coding Example 2.2 from Project B ................................................................. 66 Figure 4.18: RFI Coding Example 2.3 from Project B ................................................................. 67 Figure 4.19: RFI Coding Example 2.4 from Project B ................................................................. 68 Figure 4.20: Expanded Framework to Extract and Transform RFI Data ..................................... 69 Figure 4.21: Example of Quantitative Extracted from RFI Using Proposed Framework ............ 71 Figure 4.22: Distribution RFI from Project A Across Different Disciplines ................................ 74 Figure 4.23: Distribution of RFI Reason and RFI Type for Project A ......................................... 75 Figure 4.24: Actual Latency v/s Expected Latency for RFI on Project A .................................... 76 Figure 4.25: Distribution of RFI Property and Attribute from Project A ..................................... 77 Figure 4.26: RFI Distribution Across All Categories ................................................................... 78 Figure 4.27: Example of Multiple-View Visualization ................................................................ 80 Figure 4.28: RFI Project Dashboard ............................................................................................. 85 Figure 4.29: Interactive Features of RFI Project Dashboard ........................................................ 86 Figure 4.30: Organizational RFI Dashboard Comparing Project A V/S Project B ...................... 89 Figure 4.31: Interactive Features of Organizational RFI Dashboard ............................................ 90 Figure 4.32: Process Map of Evaluation of Prototype Dashboard Using User Feedback ............ 92 Figure 4.33: Snapshot of Proposed Request for Information Template (PDF Form) ................... 95 Figure 4.34: Proposed Approach to Visualize Information in Request for Information .............. 97 x  List of Abbreviations RFI: Request for Information CC: Construction Communication IFC: Industry Foundation Class BIM: Building Information Modeling      xi  Acknowledgements First and foremost, I would like to thank my Research supervisor Dr. Sheryl Staub-French for guiding me and giving me the confidence to achieve my goals throughout my journey during this research study. I will always be grateful to her for believing in me and giving me this wonderful opportunity to be part of BIM TOPiCS Lab. I would also like to thank, Dr. Erik A. Poirior, the postdoctoral fellow at UBC for helping me shape my thesis research from the very beginning. I thank them both for lighting this spark for research inside me which I promise to carry forward even after I leave UBC. I would also like to thank Dr. Alan D. Russell for taking out time to review my thesis.  This research study would not have been possible without the support, feedback and funding from Stantec Consultancy Ltd. I would like to express a special thank you to Aubrey Tucker from Stantec Architecture Ltd for giving me the opportunity to conduct this research study with them. I would also like to thank my colleague, Mariazel Rios Motte for helping me with this research study to validate my work. I offer my gratitude to my colleagues and friends at UBC BIM TOPiCS Lab, Centre for Interactive Research on Sustainability (CIRS) and Stantec Commercial Studio for all their support. This research study would not have been possible without the support and feedback from Stantec Consultancy Ltd, Soo, Raghav and Marcella for giving me thoughtful feedback on this thesis. Last but not the least, I would like to thank the most important people in my life, my parents for always believing in me and making me what I am today.    xii  Dedication To Amma and Appa1  Chapter 1: Introduction The construction industry is dependent on effective communication among project team members. With the increasing complexity and size of projects, the success of projects is increasingly dependent on good communication between teams (Andrews 2005; Dainty et al. 2006). Poor communication between construction participants can also cause project delays (Assaf et al. 1995). Construction data has varied formats and size and are communicated through a variety of mediums over the course of a project. This often leads to potential discontinuity and delay in communication between project team members. Songer and Molenaar (1996) stated that communication problems are the primary reason for schedule growth in the traditional delivery method, presenting an increase in Requests for Information as evidence.  Requests for Information (RFI) are the standard form of communication between the design team and the construction team whenever there is a need for clarification about the design or contract documents in a project (Andrews 2005). As per the Canadian handbook of practice for architects, RFI is a procedure for the contractor’s, sub-contractor’s, supplier’s or owner’s request for clarifications when the intent of the contract documents is unclear, incorrect, or information is missing (Hobbs 2009). And the use of RFI’s is not restricted to just document clarifications, for example, whenever there is a spatial conflict between two physical components in a construction project, RFI’s are used as tools to manage these conflicts (Song et al. 2009).The need for RFI’s may arise due to site conditions, suggestions for improvement, inconsistencies between design disciplines, drafting errors, and detail omissions (Burns 2007; Shim et al. 2016). Seldom are construction projects delivered that do not have any RFI’s. Since many construction projects run on strict schedules, the amount of time spent on these RFI’s also has an impact on all project 2  participants. A few researchers have tried to quantify the time and money spent on RFI’s from different project participant’s perspective. As per a study conducted by Hughes et al. (2016), on average there are 887 RFI’s on a construction project and an average amount of $1080 is spent on processing each RFI document. Gallaher et al. (2004) conducted a survey to quantify the cost of interoperability in U.S capital facility industry. As per their study, RFI management involves manual re-entry of data and hence, is one of the components of inadequate interoperability cost for AECO industry. In their survey of 70 organizations that included Architects, Engineers, Contractor, Owners, Fabricators and other vendors, the authors of the report quantified that design firms spend around 200 hours a month on reviewing and sending RFI documents whereas a fabricator spends 15.5 hours on each RFI. Mohamad et al. (1999) developed a model to quantify RFI processing time and quantified that on a typical RFI, the amount of time spent can be as high as 17 person-hours, where most of the time is spent on gathering and cross-referencing information. Similarly, when an electrical sub-contractor raises an RFI to the contractor, its indirect cost is 9% of the cost of the total electrical contract (Love et al. 2014). Researchers have stated in the past that inadequate or incomplete responses to RFI’s have a negative impact on project workflow and project duration (Burns 2005; Mohamad et al. 1999). Similarly, Song et al. (2005) found that the number of RFI’s and time taken to respond to them have been cited as factors that impact schedule delay. From past studies, it becomes quite evident that RFI’s have a negative impact on the project schedule and in turn, on the project cost as schedule delays and disruption in the workflow of a construction project often translate to cost overruns.  RFI is not just a means of construction communication, the fact that the RFI has been generated points out that there is something wrong, missing or unclear with the existing documents and designs. Past studies have suggested that RFI is an indicator of deficiency in design and documents 3  (Burns 2007; Philips-ryder et al. 2013; Tilley 1997). Tilley (1997) also found that the ability to respond to inquiries serves as an indicator to project performance. However, there are some significant challenges of responding to RFI’s efficiently and promptly. These include effectively managing the communication documents and making meaningful deductions from the information provided as a large amount of the information in these documents is text based and unstructured (Mao et al. 2007; Rojas and Lee 2007). Some researchers have stated that the structured manner of communication using web-based project websites can speed information flow in a project (Alshawi and Ingirige 2003; Thorpe and Mead 2001).  Current RFI management systems exist as logs on the web portal or Excel spreadsheets and are not sufficient to provide project participants with a medium to analyze the problems, their cause or even to easily look for information required in these RFI documents. Large text databases like RFI potentially contain a great wealth of factual information but in a very complex and opaque manner which is hard to analyze and understand. Song et al., (2005) claim that within the construction management domain, there is a lack of adequate visual representation due to which construction managers are still struggling with large amounts of data. But, considering the unstructured nature of the construction documents like RFI’s, it is first necessary to structure the data in the documents. Once the information has been structured, the next challenge is to develop an approach to visualize this information using computer-based data visualization software, which gives different people the ability to customize the views and analyze and explore data differently according to the required purposes considering the interdisciplinary nature of the construction industry.  Data visualization is a process of displaying data in a visual context to help people understand the data.  From past studies, we know that visualization helps humans to analyze the complex and vast 4  amount of data easily. The construction industry is an industry rich in data but lacking in information (Songer et al. 2004). Over the past few decades, some researchers have started identifying the benefits of using data visualization for construction purposes as a means of addressing the problems faced by the industry (Rojas and Lee 2007; Songer et al. 2004). Data visualizations help to communicate complex information, insights and make data more accessible and understandable to more people (Deutsch 2015). Patterns, trends and correlations within the data are recognized more easily with data visualization as compared to text-based data. The term visualization is defined by Card et al. (1999), as “the use of computer-supported, interactive, visual representations of data to amplify cognition”.   Researchers have identified that RFI’s have a significant impact on project cost and schedule. On the other hand, few other researchers have identified that there is a lack of adequate visual representation of construction data to help project managers in decision making. So, in this study, we aspired to develop visualizations of RFI data and investigate if it has potential benefits for construction project members.  But, from past studies, it has been observed that RFI documents have semi-structured data. Not many studies have tried to extract all the data from RFI documents. Hence, to develop visualizations of RFI data, we had to find a way to extract and analyze the information from the data in these RFI documents. The objectives of this study are: • To develop a framework to structure the data present in Requests for Information.  • To develop an approach to visualize data in Requests for Information and investigate the potential of this approach to support construction decision-making. A qualitative approach was employed for this research. We used the qualitative technique of content analysis to develop the framework to structure the RFI data. Content analysis is a widely-5  used approach to interpreting the meaning of the content in documents (Hsieh and Shannon 2005). We employed this technique because of the exploratory nature of the study. Once the framework was developed, we employed cross-case analysis method to check the applicability of the framework to another dataset and expanded the framework as required. Using the developed framework, the datasets were transformed into information that can be used for developing visualizations. A case study approach was employed, and data sets from two different projects were used. The data set from the first project was mainly used to develop the framework. The data sets from the second project were used to assess the developed framework and identify an approach to visualize RFI data. After analyzing the RFI’s from two projects, we developed a framework to structure RFI data. In this framework, we identified several quantitative and qualitative dimensions including time (when), spatial context (where), actor (who), reason (why), RFI Type, Domain, Property, Attribute, Entity (what) that can be used to visualise the data for analysing the information in the RFI’s. Based on self-evaluation of the developed visualizations and learnings from past studies, we chose interactive dashboards as our tool to visualize and analyze the information extracted from the RFI documents. The RFI dashboards developed in this study were presented to the project personnel and got promising feedback as well.  The remainder of this thesis is structured as follows: In Chapter 2, a summary of RFI classifications completed in past studies is provided. Further, a brief description of the motivation to use data visualization for RFI management is given, followed by few examples from past studies on visualization and current use of data visualization in the construction industry. A brief description of the setting and context of the projects used for the case study for this research study is explained in Chapter 3 to give the readers a better understanding of the analysis. Chapter 4 provides the 6  findings of the study in two parts. The iterative content analysis of the RFI’s from one of the projects was first used to develop the RFI data structuring framework. Using the developed framework, the data sets from the second project were then structured and an approach to visualize these data was developed and evaluated using current data visualization software. Chapter 5 provides the summary of this study along with its limitations and scope for future work.  7  Chapter 2: Background In this chapter, prior work on RFIs and Data Visualization in construction are presented. Based on the learnings from these studies, the research objectives and the research approach for this study were developed.  2.1 Request for Information According to Hanna et al. (2012), the purpose of an RFI is to identify issues on the field that require solutions to avoid potential contract disputes and claims. Furthermore, they suggest that RFI’s are a means to present solutions and results of questions that arise before and during construction. Past studies have identified various variables to analyze RFI’s which include (Mohamad et al. 1999; Tilley 1997): • Number of RFIs,  • Average RFIs response time,  • Percentage of RFIs responded to by the designated date,  • Number of follow-up RFIs due to insufficient response,  • Percentage of RFIs applicable to more than one consultant,  • Percentage of RFIs requiring contract modification,  • Percentage of RFIs requiring drawing revisions,  • Number of issues per RFI, and  • Method of transmission. Mao et al. (2007) state that RFI documents have both structured and unstructured data. They used the IFC model format to structure the data in the RFI documents. Other researchers for various 8  studies on RFI’s, classified RFI’s based on the nature of the RFI question, the cause for its initiation, building component and so on. For example, some researcher’s classification of RFI’s was limited to RFI types (Brazee 2014; Shim et al. 2016), whereas few researchers tried to analyze the cause or the reason for the issue. Tilley (1997) analyzed several projects and classified the information deficiencies that results in RFI’s into four groups as Conflicting Information, Incorrect Information, Incomplete Information and Questionable Information. Chin and Russell (2008) and Hanna et al. (2012) in their study of RFI’s delved deeper to understand why the RFI’s were generated and developed reason codes for RFI’s as shown in Table 2.1. Hanna et al. (2012) classified the reasons further into categories including elevation, drawing, line item, dimension, and rebar. Chin and Russell (2008) had a different perspective on the classification and categorized RFI’s based on the building components mentioned in the RFI’s, which was based on the Uniformat classification. Figure 2.1 lists the different classifications used by past studies.  9   Figure 2.1: List of RFI Type and Reason Categorization from Previous Studies10  We observed that all these studies were concentrating on categorizing the RFI’s at a very high level. Most of these researchers limited the classification to two or three levels, i.e., type, reason, and component. For our goals, we found that there is other information inside the RFI documents which needs to be extracted to give the user the benefits of analyzing these RFI’s. Hence, these categorizations developed in the past studies were not sufficient for this study. Mao et al. (2007) developed a model to connect most of the information in the RFI documents to a 3D model using a building IFC model. Though this gives the user access to all the information and visualize it spatially, it does not provide the user with the ability to assess the information using visual analytics. Andrews (2005) states the following instances when a fabricator can use RFI: • When necessary information is missing from the design drawings or specifications, or design drawings or specifications have incomplete information. • When there is a need for clarification of the design drawings or specifications.  • When there are discrepancies within the design drawings or specifications, such as conflicting information between plans and details or between the drawings and the specifications. • When the contractor or sub-contractor requests permission to use alternate materials or products.  • When the fabricator or erector requests permission to revise details for ease of fabrication or erection. Depending on the nature of the request, this could be interpreted as being a request for substitution. • When there is an error in construction or fabrication and approval to make corrections are required. 11  • When there is need to get approval for an alternate method to resolve field conflicts or constructability issues. • When the existing or as- built conditions differ from the conditions shown in the design drawings or specifications. • To confirm prior verbal understandings between the team members related to any of the preceding. A few researchers have identified the information that is present or must be present in an RFI document to achieve efficient RFI management (Hughes et al., 2013, Hanna et al., 2012). The American Institute for Architects and the Canadian Handbook of Practice for Architects (Hobbs, 2009) have also listed the information that must be made available in RFI documents.  Based on the studies mentioned above, a comprehensive list of data to be included in an RFI is given below: • Project information  • RFI Title and tracking number • Author and Responder’s Details • Subject  • Discipline affected • Date created, date required, and date answered • Discipline  • Reason Category of RFI  • Importance • Detailed questions • Suggested solution  • Related Drawing or specification number 12  • Expected impacts on cost and duration • Impact on Drawings Studies have identified the impact of RFI’s on cost, schedule and performance of a project and have also suggested how RFI’s are an indicator of document and design deficiency (Philips-ryder et al. 2013; Tilley et al. 1997). Chin and Russell (2008), established that the minimum RFI review time which is usually agreed upon at the beginning of the project is typically unrealistic and short. This means that the owner is at risk of facing legal claims due to delays caused by late RFI responses in these cases. From this, we can envision that analyzing and understanding the data in RFI’s will help in accessing the potential problems in the project design and documents, project schedule, project cost, and organization/ project team. But, there are not many studies done in the past, which try to make it possible for the construction project stakeholder to assess the aspects mentioned above. Assessing the data in the RFI could potentially help to improve RFI management and reduce RFI’s. Reduction in RFI’s and better RFI management, in turn, will have a positive impact on the project and project management and assist in decision making.   2.2 Data Visualization in Construction First, we studied previous literature to identify the potential benefits of utilizing data visualization for construction data. Following are the benefits we identified: • identifying relationships between and within various data items thus improving the ability of the construction team to interpret data and enhance decision-making (Korde et al. 2005; Russell et al. 2009) 13  • identifying the gap or trends between planned and as-built (Shaaban et al. 2001; Songer et al. 2004) • assessing the quality of a construction schedule (Russell and Udaipurwala 2000) • assessing project performance and project status (Korde et al. 2005; Russell et al. 2009) Work on visualization in construction has principally focused on visualizing the spatial building structures or sequence of construction activities (Russell and Udaipurwala 2000; Staub-French et al. 2008). Very few studies were done on visualization of construction data which is discussed later in this chapter. Moreover, even fewer studies in the past made useful exploratory work on data visualization as most researchers still focus on how to access, integrate, and consolidate construction data into a database system. Recently, some works have tried to use 3D models for visualization of construction project information. For example, Mao et al. (2007) and Opitz et al. (2014), proposed models to integrate project document data with model information using IFC building information model to help project managers to access information and manage documents more easily. Hu et al. (2016) proposed a visualization interface with timeline and keyword based query option to search, browse, and explore documents in the project archive.  Rojas and Lee, (2007) called attention to the fact that little work has been done to reflect upon the problem of how to present information properly by identifying its relationships, so that can users discover the underlying meanings. They developed a research principle to visualize construction project data. They suggest future researchers should follow their principles as they feel there is a need to first convert construction data into a meaningful form. After converting the data, visualizations can be developed that gives construction managers an opportunity to gain insights into actual project performance and make more informed decisions. It identified four steps for visualizing construction data as follows: (1) development of construction management ontology, 14  (2) formulation of strategies to visualize project control data, (3) development of interactive visualization schemes, and (4) validation of visualization schemes.  Songer et al., (2004) developed a taxonomy of visualization strategies and data types. They also identified visualization strategies for different data types. According to their research, RFI submittals have “One-dimensional”, “One-Dimensional + Time” or “Multi-Dimensional +Time” data types for which they suggested include Pie charts, Bar charts, and Histograms as the most suited visualization strategies. Shneiderman (1996), classified data types and developed seven data tasks that should be available to the user to give the user the flexibility to analyze the data according to their needs. The seven data tasks mentioned in this literature are overview, zoom, filter, details-on-demand, relate, history, and extract. These tasks will give the user the ability to glance at all the information together, filter required data and find relationships between different data. It also gives the user the ability to extract the information once the information required has been analyzed. Song et al, (2005) proposed the use of 3D model for visualizing project data including cost deviation, schedule deviation, float, budget distribution, etc. by applying the multiple project data sets to the geometric attributes of the 3D building model, such as shapes, faces, and edges through color- tone variation and motion. They suggest that this model-based visualization of project control data will help project managers assess performance, identify problems, make decisions more efficiently, and communicate with others project participants. Kuo et al. (2011) proposes a display tool called Construction Dashboard with which construction engineers can examine the construction information. They can get immediate feedback by directly interacting with the dashboard as they developed a framework to interrelate the various project information. Korde et al., (2005) and Russell et al., (2009) have focused on the visualization of construction data, 15  perceiving how data visualization can help to improve communication among project participants, help identify potential relationships between construction data which will enhance the understanding of project status and assist in efficient decision-making. For developing the visualization, they mainly focus on the information present in change orders. Chiu and Russell, (2011) developed a Construction Management Data visualization environment with the major focus on time management. They used a top-down approach to develop the interactive environment by identifying the structured way of analytical thinking and tying it with construction management processes. The authors use an “on-demand” capability to call visualizations according to the sequence required by the user which depends on the analytical thinking of different users. They developed the data visualization environment for a project and identified the following requirements for interactive features for general construction management data visualization: (i) interaction features for choosing the visual representation to be presented, (ii) interaction features for adjusting granularity and value range of data dimensions, and (iii) interaction features for viewing several visual representations which portray different aspects. Russell et al., (2009) observed that the visualization techniques developed in their study did not give the users an option to filter data and to understand the visualization was challenging due to the concentration of a large amount of data in a single view. For developing efficient data visualizations for construction document data, the key visualization techniques are visual query, interaction, linked data views and visual encoding formalism (Chiu and Russell, 2007). From studying previous work in construction data visualizations, we learned that the following (Table 2.1) are the requirements for developing good RFI Data visualizations:    16  Table 2.1: Requirements for RFI Data Visualizations Requirement Type Requirements based on Past Studies RFI Data Type  One-Dimensional, One-Dimensional +Time, Multi-Dimensional +Time (Songer et al., 2004) Visualization Strategies Pie Charts, Bar Graphs, Histograms, Tree maps (Songer et al., 2004) Visualization Techniques i. Visual Query, Interaction, Linked Data Views (Chiu and Russell, 2007; Russell et al., 2009) ii. (interaction features for choosing the visual representation to be presented, interaction features for adjusting granularity and value range of data dimensions, and interaction features for viewing several visual representations which portray different aspects. (Chiu and Russell, 2011) iii. Overview, zoom, filter, details-on-demand, relate, history, and extract (Shneiderman, 1996)  17  Chapter 3: Research Methodology In this chapter, we introduce the objectives of this study and explain the research approach employed to achieve the objectives. To help understand the context of the study, we give a brief introduction of the projects used in this case study. 3.1 Objective After studying all the past work done in this field, we identified that to visualize RFI data we had to first develop a framework to structure the information and conduct data transformation. This will provide the users an interactive way to explore all the data available at hand. Hence, the objectives of this study were: 1. To develop a framework to structure the data present in Requests for Information.  2. To develop an approach to visualize data in Requests for Information and investigate the potential of this approach to support construction decision-making. 3.2 Research Activities Based on the work by Rojas and Lee, (2007) which suggested the principles for developing visualization for construction data, the following main research activities were followed to achieve the research objectives: RA1. Development of approach to structure RFI data RA2. Development of approach to visualize RFI data RA3. Development of interactive visualization schemes RA4. Evaluation of visualization schemes 18  Figure 3.1 below shows the roadmap of this research study. In the first phase of the study, the data sets from Project A were analyzed to develop a coding strategy to structure RFI. This strategy was employed to develop an ontology to categorize and organize the information in different RFI documents. The framework was then evaluated using the data set from Project B. A study of the current use of data visualization software led to the selection of dashboards as a visualization technique for this study. In the next phase of the study, the data set from the Project B was organized using the framework developed in the first phase of the study and various visualizations were developed. These visualizations were then evaluated using feedback from industry experts. 19   Figure 3.1: Research Roadmap Showing the Relationship of All Objectives, Research Activities and Sub Processes    20  3.3 Case Study 3.3.1 Introduction A case study approach was used for this study as we wanted to explore actual construction documents and study how the flow of information takes place in an RFI in a real project setting to develop a framework which would be applicable in a real construction project scenario. Yin (2013) states that for explanatory research, case studies are a suitable methodology as they answer all the ‘how’ and ‘why’ questions and using multiple cases add to the validity and generalizability of the findings by replicating the findings in other cases (Miles et al. 2013). For this study, data sets from two projects were studied. Zainal (2007) states that the case study approach is a robust research method especially when an in-depth analysis and observation must be made. 3.3.2 Data Collection For the scope of this study, datasets from two different case studies were used. Table 3.1 gives a brief overview of both the projects along with the data collected and analyzed for this study. As part of the case study, we collected quantitative and qualitative data to address the research question. Additionally, for Project B regular check-in with the project team was held to get constant feedback which helped us identify the challenges and scope for improvement. The data sets from Project A were mainly used to achieve the first objective of this study, i.e., to develop the framework to structure the data in the RFI’s. In the next phase of the study, datasets from Project B were analyzed to develop data visualizations of RFI data, which is the second objective of this study.  21  Table 3.1: Project Overview and List of Data Collected Project Project A Project B Type Institutional Commercial Location Edmonton, AB North Burnaby, BC Budget 260 Million 245 Million Area 37,100 sq.m. 162,580 sq.m. Delivery Method Design Build Construction Management Number of Stakeholders 29 30 Data Analyzed • RFI • Construction Communication Documents • Supplemental Instructions • Clash Reports • Coordination Meeting Minutes • 2D drawings • 3D Model • RFI • 2D Drawings/ Specification • 3D model Level of Interaction with Project Team none Constant feedback from project team Time of Study January 2016- August 2016 October 2016-December 2016 22  Project A was the construction of a public institutional building in Edmonton, Alberta, Canada. It was procured under a design-build contract with the Government of Alberta. The project team was made up of 29 different stakeholder organizations. Here, the term stakeholder is referring to the various project team members like contractors, consultants, sub-contractors, owner, fabricators and so on. For this study, we analyzed 1400 RFI and Construction Communication documents along with Conflict reports, supplemental instructions, coordination meeting minutes, 2D drawings and 3D models documented on the online construction management platform. The following table shows the documents and number of documents studied from this project for this research study.  A web-based construction management software was used to store and manage all the project documents. All the project stakeholders had access to the platform.  Table 3.2: List of Documents Analyzed from Project A Project Delivery Issue Number of Documents (files) Request for Information 167 Construction Communication 1226 Supplemental Instructions 81 Conflict Report 120 Total 1594 Project B was the construction of a private commercial building in North Burnaby, British Columbia, Canada. It was procured through Construction Management. There were 30 different stakeholders on this project. For this study 500 RFI documents between April 2015 and January 2017 were analyzed. The RFI’s were documented on the Project Architects internal database in 23  folders. We also analyzed 2D drawings and 3D models whenever required to get a better understanding of the RFI issue context. We had access to these documents from the Project Architects internal database. The documents were stored in separate folders according to project phase and document type on the project architect’s internal database. An Excel spreadsheet was used to maintain the RFI log. 3.3.3 RFI Format and Flow of Information For Project A, we had access to the RFI documents sent from the contractor or owner and the responses sent from A/E consultant mostly in the form of Construction Communication (CC) Documents. The first step was to understand the inter-relationship between different communication documents and the flow of information in a construction project. In order to do this, we selected a conflict issue which was identified on site during construction and tracked the flow of communication between the project team members. Figure 3.2 shows the flow of communication in the documents that we analyzed with respect to this issue. On identification of the problem on the site, an RFI was issued by the contractor which was discussed in the coordination meeting to find a resolution with the Architect, after which a response was drafted by the architect in the form of a Construction Communication. This entire cycle of flow of information took two months to find a resolution to the problem to this particular RFI. In our study, we first analyzed the RFI to get an understanding of the problem. In cases where the cause of an issue was not very clear or if some information was missing regarding why the issue arose or any other significant detail about the issue then coordination meeting minutes, clash detection reports, 2D drawings or 3D model were analyzed to trace the issue and extract information from them. Based 24  on the scope of our analysis for this case, Figure 3.3 shows the flow of information between project team members in the documents that we analyzed. 25   Figure 3.2: Flow of Communication Documents for an Issue Between Project Participants26   Figure 3.3: RFI Workflow for Project27  Figure 3.4 and Figure 3.5 below show the RFI and Construction Communication document format used in this project. In this project, a Construction Communication (CC) is a response from the A/E consultant to internal RFI from the contractor. We did not have access to internal RFI’s as they were not documented on the web-based project management platform and hence used CCs instead of internal RFI’s for this project. From Figure 3.4 and Figure 3.5, you can see that both the RFI and CC document have an almost similar format.  The only explicit difference is that in the main body of the CC document, the response is mentioned first followed by the question to the response given. Throughout this study, whenever we refer to an RFI it includes CC as well.  28   Figure 3.4: Snapshot of RFI Template from Project A  29   Figure 3.5: Snapshot of CC Template from Project A In the case of Project B, we had access to RFI documents even from the sub-contractors and the fabricators which helped us get a deeper understanding of RFI’s and a complete picture of the RFI process and information flow as shown in Figure 3.6.  However, this also posed a problem as there  Explains Query in the RFI 30  were too many formats of same RFI document which made the manual process of extracting data from these documents tedious. The RFI template used in this case was very similar to the previous case. But during the analysis, the author noticed that all the RFI’s mentioned the location, i.e., the Level and the Zone where the issue was located. In Project B, this was explicitly mentioned in the structured top section of the RFI document. Whereas in Project A, it was very rarely mentioned in the body or the title of the RFI. Hence, while extracting the data in the RFI, the level and zones for each issue were also organized. In this chapter, we explained the RFI template used and the flow of information in the RFI’s between the project team members. In the next chapter, we will explain how we analyzed these datasets to develop the framework to structure RFI information and the approach we used to develop visualizations for the same.  31   Figure 3.6: RFI Workflow in Project B32  Chapter 4: Findings This chapter gives a detailed explanation of the process of evolution of the framework using the datasets from Project A followed by the evaluation of the framework. Next, it explains the approach used to develop the visualizations for which the datasets from Project B was used. 4.1 Development of Approach to Structure RFI Data This section explains the iterative process employed to develop the framework. We emphasize on how the documents were coded to interpret the content in the documents. For this, we employed the qualitative research technique of content analysis. Some researchers may use coding as a preparatory work, but according to Miles et al., 2014, “coding is deep reflection about and, thus, deep analysis and interpretation of the data’s meanings.” Since the major focus of this study was the development of the framework, a detailed explanation of the content analysis and the evolution of the framework is provided. 4.1.1 Development of Coding Strategy Before explaining the process of how we analyzed the RFI documents, a brief explanation about the data structure of the RFI’s analyzed is given (Figure 4.1). In this project, out of the 1400 documents analyzed, 167 were RFI to the client, and the rest were CC’s generated by the consultant as a response to RFI’s issued from the field.  A typical RFI document has information in the structured format at the top section of the document which includes title, important dates and the participants involved (Mao et al., 2007). This is followed by an unstructured main body which includes the question and the answers to the queries, which is the focus of our study here. The 33  participant who initiates the RFI asks the question according to the situation on site. This is then answered by the responsible project participant by filling the response in the RFI document below the question in the main body or by sending a separate CC. But for the development of the coding strategy, we first analyzed the 167 RFI documents as the format of a CC document was very close to an RFI document, except that in the CC the response comes first followed by the question in the bottom. As mentioned before, for this study, we were interested mainly in the ‘Question’ and ‘Response’ body part of the documents as the rest of the RFI document was already in a structured format.  34   Figure 4.1: Structure of RFI Document35  The political scientist Harold Lasswell developed the core questions of content analysis: "Who says what, to whom, why, to what extent and with what effect?” (Lasswell, 1948). In this study, we asked the core questions: Who says what to whom, why, and when? This gave the researcher a good starting point to analyze the documents and structure the data in the documents. After carefully reading the 167 RFI documents, it was realized that the initially proposed core questions were not sufficient as the document has much more to say about the issue. Hence, the core question was expanded to: Who says what to whom, why, when and about what? Then, a strategy, shown in Figure 4.2, was developed to extract and structure all the information available in the RFI documents studied. Even though all RFI documents do not have the same format, but more or less all documents have the following information mentioned in Figure 4.2. However, there can be varied types of RFI’s, or the RFI could have been generated due to various reasons, and they also have a varied range of information in each and every document. Hence, there was a need to develop an ontology for RFI Type, RFI Reason, RFI Domain and Property categories (Figure 4.2). What is the nature of RFI?Why did the RFI come up?What entity the RFI focuses on?Which property of the entity is under question in the RFI?TypeReasonDomainProperty Figure 4.2: Coding Strategy 36  4.1.2 Development of Ontology Once the strategy to structure RFI data was identified, an iterative coding process was employed to develop the ontology. For this part of the study, both RFI (Total 167 documents) and CC (First 500 documents out of 1226 CC documents) documents were used.  Mao et al., 2007 points out that the content of the RFI documents are filled by construction project participants which are dependent on their personal experiences and writing styles, making it almost impossible for computers to understand and characterize without additional data. Since these documents are drafted and written by project participants; we also observed that the choice of words depends on the personal choice. For example, “conflict in design” has been used in some RFI’s, which means inconsistency in design documents and not a physical conflict which can lead to confusion. Sometimes, there are repetitions of the same question or response by the contractor or architect who simply copies the question most of the time, while forwarding it to the other project team members which can lead to duplication. Some of the RFI documents had scanned hand written comments and hand drawings which were difficult to extract using computer tools.  Hence, for this study, we chose to code the documents manually instead of using any of the coding software because of the ambiguity in the document content and wordings. Both deductive and inductive types of coding techniques were employed to develop the ontologies. In the inductive type of coding, the codes develop over the process of document analysis whereas, in deductive types of coding, codes are deduced before analysis based on the researcher’s knowledge of the nature of the data content. The different cycles of coding are explained below: Cycle 1: Inductive type of coding process was used to develop the Type and Reason ontologies as shown in Figure 4.3. We first analyzed the content of the documents and summarized it in a word 37  or phrase. Next, we analyzed the summaries to identify patterns and categorized similar ones under one Type or Reason code to develop the Type and Reason categories. In case, the content of the RFI was incomplete or ambiguous; we analyzed the Conflict reports, Coordination Meeting Minutes, 2D drawings and 3D models to find the missing information.  38   Figure 4.3: Flowchart of Coding Process for Type and Reason Category 39  In the first round of coding, the author identified the type of the issues being raised based on the wording and nature of the question. For example, one of the RFI question content says,  “requests to revise the electrical drawings, and as a result move the power source…”.  After carefully reading and reflecting on the question content, the author summarized and categorized this RFI type as a “Design Revision” as it is a request to change the current design to move the location of the power source. In the same way, all other RFI’s which were a request to make a change in the design document were summarized and categorized under Design Revision. Another RFI question was: “Due to the unavailability of the epoxy resin work surfaces for the Fume Hoods from the supplier, we would like to suggest an alternate material to be used.” This RFI is suggesting an alternative material for one of the products to be used in the project. The nature of the question was summarized as “Alternative”. Next, after analyzing the summaries of all the RFI’s, we saw many other RFI’s were suggesting an alternative product or location or size or method of installation and so on. Hence, we grouped all these RFI’s under the category of “Design Alternative”. Cycle 2: In the next round, we delved deeper to understand why the issue was being raised, as we envisioned that asking the question why the issue originated would help the project participant understand how the issue could have been addressed before. If one reads the above example again, you will observe that the RFI initiator or writer had mentioned why he is suggesting the change, i.e., the unavailability of material in this case. This is related to the second question in our coding strategy, i.e., “why did the RFI come up”. This and similar RFI’s were summarized and categorized as Material Unavailability under the Reason category.  This is illustrated by another example below: 40  “Drawing E.2.02- Level P1, Part 1 Power Plan shows P-26, DCW Booster Pump in the Boiler Room. However, drawing M3.02- Mechanical Fan Room 2 indicates the same P-26 pump to be in Fan Room 2.” And also “location discrepancy” was mentioned in the RFI body. Hence we summarized this RFI cause as design discrepancy. But, many other RFI’s also mentioned inconsistency between designs. Finally, while developing the RFI reason category, both discrepancy and inconsistency were grouped under Design Inconsistency category.  Cycle 3: In the third round of coding, the focus was on “what the issue is about” and simultaneously ontologies for three different categories were coded. The coding process used for this round was slightly different when compared to the first two rounds. In the previous two rounds, we analyzed the documents to develop the codes along the process. Whereas, in this round, we had already deduced the codes based on our knowledge of the RFI data content from past studies. Mao et al., (2007) claims that most of the RFI documents have information which can be extracted using IFC Building Information Model. RFI documents are communications about construction products and hence include geometric and non-geometric data about building components.  Cavka et al., (2016) classified the geometric and non-geometric properties of building components and developed a classification for the quality of information in BIM. This classification served as a good starting point to analyze and categorize the information in RFI for this study. Hence, for this cycle of coding, the codes were adapted from Cavka et al., (2016). Based on these codes, the domain category was classified in Information and Product. A Product is a physical deliverable, for example, a wall, a window or a room. The digital content of a document is the Information in the project documents, i.e., the graphics of the design or the text of a document. Within the Product category, the RFI’s data was further categorized into Component and Space whereas Information 41  category was classified into Content and Structure. The flowchart below explains the coding steps followed for developing Domain categories.  42   Figure 4.4: Flowchart of Coding Process for Domain Category43  Based on codes adapted from Cavka et al., (2016), we used an initial Property codes like size, location, function, type, quantity, etc. to analyze the RFI’s. The categories were then revised whenever needed based on the patterns observed during the content analysis of the RFI’s. The Information domain was categorized again based on the codes adapted from Cavka et al., (2016). For example, one of the RFI mentioned: “the architecture drawing does not have the recent modifications” which was coded as “Current Relevance” Similarly, another RFI said “the elevation drawing for this section is missing” which was coded as Missing. Again, the codes were revised depending on the patterns observed during the analysis. Finally, after three rounds of iteration, the final ontology to organize RFI data was developed as shown below Figure 4.5. 44   Figure 4.5: Proposed Framework to Structure RFI Data45  Table 4.1 to Table 4.4 give a detailed description of the RFI Type, Reason, Domain, Element and Property codes. To show how the RFI’s were coded, we illustrate the process with five examples (Figure 4.6, Figure 4.7, Figure 4.8, Figure 4.9, and Figure 4.10). These examples have been chosen to cover a varied range and combination of codes developed in this study. Another point to note here is that it is possible that several RFI Questions and Responses coexist in one RFI document. In this study, for coding and organizing the data, each question and response set has been considered as a separate unique issue.    46  Table 4.1: List of RFI Types with Description Type Description Design Revision A change in design or request for change in plan/ drawings made Design Clarification Clarification about the content of plan/drawings or intent of the design Construction Coordination A request to change the sequence of process or clarification regarding installation, process or schedule of construction Design Communication Communicating decisions made prior in a meeting for example, to the team Scope Clarification Clarification about who is responsible for the work or the extent of work/scope Design Alternative Suggesting an alternative/substitution for the design which is more feasible or for better coordination Design Review Communication of document for review from other disciplines or request to review updated design Information Request Requesting more details about a component or requesting for a plan/section/elevation/drawing Other Any other miscellaneous type    47  Table 4.2: List of RFI Reason Categories with Description Reason Description Design Inconsistency Discrepancies in design or inconsistency between plans/sheets/section/elevation or interdisciplinary drawings. Design Coordination Coordination of design between different discipline Conflict Physical/ Spatial conflict between components in the design Design Error Typo or mistake in calculation Constructability Issue Difficulty in constructing as per the design on site Requirement Mostly change in design required to suit the product Code Requirement Requirement to meet code specifications Owner's Request Request made by owner Contractor's Request Request made by Contractor Value Engineering Cost reduction Missing Info Information not available regarding a particular component in the plan/drawing or Section/Elevation detail is missing Design Modification Updates/ modification made in the design as the project proceeds Confirmation To verify/approve or confirm the information assumed by the sub Material Unavailability Material specified not available or is very expensive Other Any other miscellaneous reason not mentioned above  48  Table 4.3: List of RFI Domain and Element Categories with Description Domain Description Information Digital or textual content of documents/graphics of design Product A physical deliverable of the project Element Description Content The content matter of the information Structure Presentation of the content, i.e., how the information has been presented on the documents/design/drawings Component A physical asset or element like wall, door, window, etc. Space A physical deliverable area like room    49  Table 4.4: List of RFI Property Categories with Description Property Description Accuracy The preciseness of the information Reliability A check of whether the information is trustworthy Missing Required information not present in the document/drawing Clarity  The presentation of the information is not clear Current Relevance The information provided is up-to-date or not Consistency The information provided is consistent through out all documents Understandability The ease of understanding of the textual content of the documents Accessibility The ease of availability of the information Size Dimension or Magnitude of product Quantity Amount or Number of product Type Kind or category of product Function Use of the Product Condition Requirement for the product like access or clearance Performance Product properties required for performance like thermal property Shape Geometrical Definition of product Relationship Spatial or connection relationship between products Location Place or position of the product 50  Example 1.1: This example is an extract from an RFI initiated by the contractor during the first year of construction in November 2014 to the consultant. The contractor is suggesting to use the standard screen as the touch screen currently specified in the specification has a negative impact on cost. Figure 4.6 shows how we coded this RFI extract.  Figure 4.6: RFI Coding Example 1.1 from Project A Example 1.2: This RFI response was issued by the structural consultant which was then, forwarded by the consultant to the contractor because the contractor had installed eight piles out of tolerance. Hence, the repair was required. (Refer Figure 4.7) 51   Figure 4.7: RFI Coding Example 1.2 from Project A Example 1.3: This RFI was issued by the consultant on being suggested by the structural consultants to the contractor to change the concrete used for columns from 30Mpa to 35Mpa to meet concrete strength requirement. (Refer Figure 4.8) 52   Figure 4.8: RFI Coding Example 1.3 from Project A Example 1.4: This example is an extract from an RFI issued by the contractor in the first year of construction in September 2014. The contractor had problems drilling piles as per design in a location due to the existing concrete. Hence, the contractor sends this RFI to the consultant requesting guidance from the structural consultant. (Refer Figure 4.9) 53   Figure 4.9: RFI Coding Example 1.4 from Project A Example 1.5: This RFI was issued by the Electrical Consultant on noticing the discrepancy in the shop drawings regarding the power supply. The RFI was then issued by the consultant to the contractor to verify the drawings and confirm the accuracy of the drawings. (Refer Figure 4.10) 54   Figure 4.10: RFI Coding Example 1.5 from Project A 4.1.3 Evaluation of Framework Due to the use of a qualitative approach for this study, quality concerns play a central role in evaluating the process used to develop the framework and the final product, i.e., the framework. Though the quality of qualitative studies cannot be tested using hardbound rules, there are tests or steps that can be used to check for the quality of the study and findings. According to Miles et al. 2013, there are five main criteria of quality, namely, Objectivity/Confirmability, Reliability, Internal Validity, External Validity and Utilization/Application, that has to be checked for in a 55  qualitative study. There are many possible ways of assessing for these criteria which are sometimes overlapping; the methods used in this study are explained below.  4.1.3.1 Objectivity/Confirmability One of the many ways to provide for objectivity/confirmability of the study is by providing a detailed explanation of the study’s methods and procedures so that it can be checked and the same process can be followed by any external person (Miles et al. 2013). In this study, the content of the RFI documents was filled by project participants, and hence the choice of text and phrases was depended on the RFI writer’s personal choice and writing style. Hence, the coders were aware of the possibility of assumptions while coding the text in these documents.  Hence, 14 RFI issues which were of the Design Revision type were chosen. The reason for choosing Design Revision type was that the changes made in the model could be easily identified and it can be verified whether the coder has understood the context of the RFI document accurately. The issues in these RFI’s were traced back to the 3D model and tracked and then, we checked whether the content analysis of the RFI issues matches with the design evolution. This process is explained here with two examples.  Example 1: “…the concrete block wall in this location be shifted 300mm to the east to allow for the water closet carrier.” According to the content analysis of this RFI issues, it is a design revision of a component, and the location of the component is changed. Design RevisionProductComponentLocationPosition When the author tracked the issue in the 3D model, the location, i.e., the global x-coordinate of the wall was changed by 300mm (Figure 4.11 and Figure 4.12) as identified by the author during 56  the content analysis. Analyzing the model helped us understand the context of the RFI issue even deeper and realize why the issue mentioned in the RFI body came up in the first place. For this RFI, the water closet carrier mentioned in the RFI was not modeled in the 3D model. A water closet carrier is a carrier system which hangs on the wall not touching the floor and connects the water pipe and the water closet. Hence, it could not be identified during clash detection, and the RFI had to be issued later to resolve the issue. But, we did not carry out such a deep root analysis of each and every issue in all the RFI’s documents as it outside the scope of this study.  57   Figure 4.11: Snapshot for Example 1 of the Model Before Revision 58   Figure 4.12: Snapshot for Example 1 of the Model After Revision59  Example 2: “Refer to Consultant Recommendation for the addition of a 'P1' wing wall at the mop sink location” According to the content analysis of the CC, it is a Design Revision for Coordination of a physical component with respect to increase in the Quantity, i.e., Number of P1 type wall. Design RevisionCoordinationPhysicalComponentQuantityNumber When this issue was tracked in the model, we could see that a P1 wall was added adjacent to the mop sink as mentioned in the CC, i.e., the quantity of P1 wall changed from three to four. (Figure 4.13 and Figure 4.14). The same process was followed with the remaining issues in the 14 RFI’s and all of them showed that the content analysis matched the evolution of the design in the model. 60   Figure 4.13: Snapshot for Example 2 of the Model Before Revision  Figure 4.14: Snapshot for Example 2 of the Model After Revision 61  4.1.3.2 Reliability One of the ways to establish reliability is showing consistency or stability over time and method. The analysis of data for this case study was done in two phase. First, all the RFI’s from the design and construction phase of this construction project were analyzed by two coders using the same method of coding. Later, the RFI’s which developed during commissioning phase were also analyzed to make sure the same framework applies to data sources from different phases of a project. And the method used by the two coders was also consistent which is explained more in detail in the next section below.  4.1.3.3 Internal Validity Here, we were checking for the credibility of the study and the finding. Triangulation of methods is one way of internal validating (Miles et al. 2013). Since, in this study manual coding technique was used to develop the framework, the method of investigator triangulation was employed. Another coder was asked to code the remaining 700 CC documents using the same coding strategy after carefully explaining to the other coder, the framework, and the ontology. The same documents were coded by the author as well. To measure the extent of inter-rater reliability, kappa statistic was used over percent agreement as it takes into account for the possibility that raters guess on at least some variables due to uncertainty. Hence for this study, Cohen’s Kappa (κ), which was introduced by Jacob Cohen in 1960 was used, as it measures the reliability between two raters. The formula for κ is: κ = po – pe 1- pe 62  Where po is the relative observed agreement among raters, and pe is the hypothetical probability of chance agreement, using the observed data to calculate the probabilities of each observer randomly saying each category. If the raters are in complete agreement, then κ = 1. Table 4.5 shows the Kappa value determined for the different categories of coding for this study. The following values were calculated separately for data coded per category by both the coders. Contingency tables were developed for each category separately as shown in Figure 4.15 and kappa value was calculated using the equation given above.    Figure 4.15: Sample Chart for Contingency Table   63  Table 4.5: Kappa Value for Different Categories of Coding Category Kappa Type 0.88 Reason 0.78 Domain 0.87 Element 0.88 Property 0.92 Attribute 0.87 Landis and Koch (1977) proposed benchmark scale for kappa value. They suggest that the extent of agreement can be qualified as “Poor”, “Slight”, “Fair”, “Moderate”, “Substantial”, and “Almost Perfect” depending on the magnitude of Kappa. A Kappa value below 0% indicates poor agreement level whereas values between 0% and 20% indicate slight agreement. Similarly, kappa values between 40% and 60% indicates a moderate agreement level, while ranges of values (60% − 80%), and (80% − 100%) indicate substantial and almost perfect agreement levels respectively. According to this, the coding process used to develop the framework is significantly reliable except for the reason category which is a little below 0.80. We wanted to identify, where was the most disagreement or ambiguity within the reason category for which we used the percentage agreement method. According to percentage agreement method, there is an agreement of about 80% between the two coders. It was noticed that within the 20% where there was disagreement, 90% of the disagreement was with respect to Requirement code in the Reason category. This brought to our notice that there was ambiguity with respect to this code and how it was described. Because of the term “Requirement” and the previously loosely termed description, the second coder had coded all 64  the RFI’s which had the text “require” as a Requirement. Hence, we separated Code Requirement as a separate category and described “Requirement” as a necessity or requirement to meet owner’s/ contract/ procured product requirements.  4.1.3.4 External Validity/Generalisability One of the ways to check for generalisability of the findings is by replicating the findings in another dataset (Miles et al. 2013). Hence in this study, using the developed framework from Project A, datasets of Project B were analyzed and organized to check whether the framework developed is valid to extract and structure all the data in the RFI documents from another project. Around 500 RFI documents from Project B were studied for this using the same manual analysis method. Using the framework, we could extract the data from the main body, i.e., the Question and Response part of the RFI document and the ontology developed in the previous case still holds good for the dataset of Project B. Figure 4.16, Figure 4.17, Figure 4.18 and Figure 4.19 show extracts from the RFI’s from Project B and how the data in the RFI sample can be extracted using the framework developed using the same strategy used for Project A datasets. Example 2.1: This example is an extract from an RFI issued by the mechanical sub-contractor to the contractor sharing his concerns about a pipe running in through elevator room. This RFI was then forwarded to the project architect by the contractor for verification. (Refer Figure 4.16) 65   Figure 4.16: RFI Coding Example 2.1 from Project B Example 2.2: This example is an extract from an RFI initiated by the electrical sub-contractor to the contractor when they couldn’t find the required information in the given document. There was a clash on site, and they needed the information for coordinating lighting and mechanical design. (Refer Figure 4.17) 66   Figure 4.17: RFI Coding Example 2.2 from Project B Example 2.3: This example is an extract from an RFI document sent by the rebar fabricator to the contractor when they observed design discrepancy between two sets of drawings. The contractor further forwards the RFI to the Architect. (Refer Figure 4.18) 67   Figure 4.18: RFI Coding Example 2.3 from Project B Example 2.4: This example is an extract from the RFI document initiated by the canopy fabricator to the contractor who just wants to confirm the details of the shop drawings. (Refer Figure 4.19) 68   Figure 4.19: RFI Coding Example 2.4 from Project B After analyzing the RFI template for Project B, we observed that all the RFI’s had the level and the zone to which the RFI was referring to in the top structured part of the RFI template. Hence, this data was also extracted, and the framework was expanded as shown below in Figure 4.20.  And we also expanded the framework to add the Entity level which adds more level of granularity to our third question in the coding strategy, i.e., which item is the RFI talking about?69   Figure 4.20: Expanded Framework to Extract and Transform RFI Data70  4.1.3.5 Utilization/Application The findings of this qualitative study were useful to structure the unstructured data in RFI document and transform qualitative data to quantitative date which can be used for visualization. Figure 4.21 shows the transformation of data in the Question and Answer part of first 50 RFI’s from Project A. This was the problem we identified, and the framework developed helps to overcome this problem of unstructured data in documents. In this framework, we have identified several quantitative and qualitative dimensions like time (when), spatial context (where), actor (who), reason (why), RFI Type, Domain, Property, Attribute, Entity (what) that can be used to visualise the data for analysing the information in the RFI’s. Domain, Property, Attribute, and Entity answers the same question as to “what is the issue about” but at a different level of granularity. Whereas, for the spatial context we have two different levels of granularity, namely, Level and Zone within the project. 71   Figure 4.21: Example of Quantitative Extracted from RFI Using Proposed Framework72  4.2 Development of Data Visualization Approach In this section, we will show few examples of visualizations developed and how it can offer potential benefits to construction project participants. The scope of the study is to develop an approach to visualize the information in the RFI documents using the framework developed in the previous section. This study has not gone into the details of data visualization to choose how much data should be presented or how it should be presented to gain maximum benefits as this was outside the scope of this study.  4.2.1 Development of Visualizations to Select Visualization Technique For this section, information extracted from Project A datasets were used. The extracted information was stored in Excel spreadsheet which is the data that has been used to develop various visualizations in this sub-section. The nature of data extracted from this project was “multi-dimensional + time” and hierarchical (Refer Figure 4.20). Hence, we chose bar charts and tree maps as suggested by Songer et al., 2004.  Figure 4.22, Figure 4.23, Figure 4.24 and Figure 4.25 are some of the visualizations developed during this study. We can observe from Figure 4.22, that more than 50% of the RFI’s were related to architectural discipline in this project. From Figure 4.23, it can be observed that the most prominent type of RFI in this project was Design Revision type for Coordination reasons. 73  In Figure 4.24, it can be observed that the project team was not responding to the RFI’s within the expected period. To understand this, we calculated the actual latency and the expected latency using the RFI Initiation date, RFI Expected date and RFI Resolved date. The actual latency is the time between the initiation date and the resolved date. The expected latency is the time between initiation date and the expected date. From Figure 4.25, it can be seen that most of the RFI’s were referring to the location of a project component. We observed that through these visualizations, patterns within one category could be identified easily, but it is difficult to identify the relationship between all the categories. For example, if we wanted to analyze how many design revisions were because of coordination reasons of location and size of mechanical components, with these individual views, it was not possible to identify this. Hence, we developed a Sankey diagram shown in Figure 4.26 to view all the information in a single view and to understand the relationship between each of these categories. Sankey diagram was first used by Matthew Henry Phineas Riall Sankey in 1989.74   Figure 4.22: Distribution RFI from Project A Across Different Disciplines  75   Figure 4.23: Distribution of RFI Reason and RFI Type for Project A  76    Figure 4.24: Actual Latency v/s Expected Latency for RFI on Project A 77   Figure 4.25: Distribution of RFI Property and Attribute from Project A  78   Figure 4.26: RFI Distribution Across All Categories     79  From the above Sankey diagram, all the information can be visualized in one view which could not be analyzed from the individual visualizations explained above in Figure 4.22 to Figure 4.25.  But, even though the relationship between various categories can be understood, it concentrates a lot of information in a small area which was one of the limitations of the studies done on construction data visualization in the past. Also, these static visualizations do not provide filter options to the users. Based on our learnings from past studies and our observations from the visualizations developed, we envisioned that having multiple linked views as shown in Figure 4.27 with filter and query options will help analyze all the information available rapidly. The concept of linking views is connecting different views where the user has the freedom to explore the data interactively. When there is ability to link multiple views, the user can make better sense of data. This is because now as all the data need not be concentrated in one single view but at the same time can be viewed together by selecting the data that is required using filter option. 80   Figure 4.27: Example of Multiple-View Visualization 81  4.2.2 Selection of Data Visualization Technique Based on the learnings from past studies, the objective of this study was to develop data visualizations techniques which are interactive, have linked views and allows filter options. Additionally, the visualization software should support the following tasks: Overview, zoom, filter, details-on-demand, relate, history, and extract. Current web-based data visualization software like Tableau and Microsoft Power BI provide an interactive visualization with filter options, coordinated views. This can be accessed by all project team members online. Hence we chose to develop interactive RFI management Dashboards using these web-based Data Visualization software. According to Kerzner (2013), “the primary purpose of a dashboard is to display all of the required information on a single screen, clearly and without distraction, in a manner that can be assimilated quickly”.  Some typical benefits of dashboards are as follows: • Improved decision making and performance as the organization can easily identify and correct negative trends (Rasmussen et al. 2009) • Detection and discussion of project successes and failures as everyone is on the same page (Pauwels et al. 2009) • A construction project status dashboard could serve as a database system to store data for a given project and to serve as historical data for other similar projects (Rasmussen et al. 2009) • Dashboard can be used to communicate to various stakeholders; each stakeholder may have different views (Maheshwari and Janssen 2014) • Ability to identify and correct negative trends (Kerzner 2013) 82  After Identifying the potential benefits offered by interactive dashboards, we developed few example dashboards for RFI management using the datasets from the case studies and evaluated its benefits by comparing it with past literature and by taking feedback from industry personnel.  4.2.3 Development of RFI Dashboard The process of development of visualization was more of a trial and error method where we tried to visualize different categories of RFI data and see how the relationships between the different categories could be best visualized and analyzed by a construction project team. Finally, many different visualization schemes were developed. We discuss two of them in the following sub-section.83  4.2.3.1 Development and purpose of Dashboard 1- RFI Project Dashboard: Dashboard 1 was developed using the data organized from Project B RFI’s. The purpose of this visualization is: • to analyze the distribution of RFI’s over time across different levels and zones of the project  • to identify trends with respect to the components and their properties addressed in the RFI questions.  With the Dashboard 1, we can assess, • To date, what is the distribution of RFI’s with respect to space and time? • To date, what is the distribution of RFI’s context and what are the potential reasons for the issues? • What is the relationship of reasons with respect to time, space and component? • What is the distribution of RFI with respect to project components and component properties? Figure 4.28 and Figure 4.29 shows the dashboard and how the visualization can be used to assess the above by filtering required data. Since the construction industry is very spatial oriented, we integrated a heat map of the floor plan of the building to help the project participants get a spatial context of the issues being analyzed and identify the sensitive areas of a project. Considering the one-dimensional nature of the data in each view in the dashboard, we chose to use bar graphs and pie charts to represent the data as the construction industry is already accustomed to reading and analyzing them in the project reports. Even though the data was hierarchical in nature, we did not 84  use tree maps to represent the data as there was a lot of data and it was difficult to understand considering a large number of categories. 85   Figure 4.28: RFI Project Dashboard 86   Figure 4.29: Interactive Features of RFI Project Dashboard 1 User Action Reaction 87  As we can see in figure 4.28, the user can see that the second zone from right at the bottom is very saturated and the user can drill down to see why are the issues coming by just clicking on this zone on the screen. This will filter and highlight the information from this zone in all the views as shown in Figure 4.29. This gives the user the ability to identify the relationship between all these dimensions.  It can be seen that most of the RFI’s were generated because of design inconsistency in the location and size of walls, openings, and slabs.  This dashboard can help to identify negative trends within a project that can help a project manager prioritize his/her time and take corrective steps. This interaction is just used as an example to explain the use of the dashboard here. The user has the flexibility to select or filter information from any other view in the dashboard to analyze the information. 4.2.3.2 Development and purpose of Dashboard 2- Organizational RFI Dashboard: The purpose of this dashboard is to see how visualization can help a project manager compare two projects by assessing: • To date what is the total number of RFI’s and their distribution over time? • To date what is the RFI responsiveness of the team as compared to the expected Response time? • To date, why are most of the RFI’s coming? For this, we used the RFI’s (excluding CC) from both Project A and Project B. We understand that both these projects are not from the same organization. But, due to lack of time, we could not analyze datasets from another project from one of these organizations. Hence, just to develop an example and identify its potential, we have used Project A and Project B datasets for developing this dashboard. Again, we have used Bar graphs and Pie charts as used in the previous example 88  for the same reasons mentioned above. From Figure 4.30, the user can see that most of the RFI’s are coming from Project B. Since, the current data visualization software has the option to filter information, the user can choose to see information only from Project B to see why the problems are coming up and evaluate their relation with time as shown in Figure 4.31. Information can also be restricted to a particular time as shown in Figure 4.31.89   Figure 4.30: Organizational RFI Dashboard Comparing Project A V/S Project B 90   Figure 4.31: Interactive Features of Organizational RFI Dashboard1 2 3 91  4.2.4 Evaluation of Data Visualization According to Rojas and Lee, 2005, the best option for learning about the effectiveness and appropriateness of visualization is a validation of visualization schemes for actual construction projects.”  However, considering the financial and time constraints of the project, this was difficult to achieve in this study. Therefore, we used two methods to evaluate the developed RFI Dashboard. First, we evaluated the potential benefits and usefulness for the users, i.e., project manager and construction project key personnel.  Next, we compared the developed RFI Dashboard with construction data visualizations developed by past researchers. 4.2.4.1 Evaluation of Prototype Dashboard using User Feedback The evaluation of the dashboard process overlapped with the development of the dashboard and the selection of the project for the case study as shown in Figure 4.32. We used feedbacks from the users to design the dashboard and also to evaluate the dashboard. Hence, we explain the process in detail under this section. The user group was selected naturally along with the selection of Project B for the case study. We selected the Project Manager and two other key personnel from one of the stakeholder team for Project B as these were the key decision makers who would be using the Dashboard. Before developing the dashboard, we had a discussion with these project personnel to understand their needs. Based on one of these feedbacks from the industry personnel, the heat maps of the floor plans were added which is one of the features of the current Data Visualization tool. The key requirements according to the feedback was to develop visualizations that would help analyze spatial context of RFI issues, time context of the RFI’s, reasons and the components affected by these RFI’s. Further, we chose to regularly check the usefulness of the 92  visualizations developed through regular informal discussions with the project personnel to gather their opinions.    Figure 4.32: Process Map of Evaluation of Prototype Dashboard Using User Feedback This included showing different versions of the visualizations to a group of industry personnel including the project manager of the project and other senior management. We got regular feedback from the team and incorporated the feedback received to make the visualizations more useful. Overall, there was a positive feedback by the key project personals that the visualizations looked like a promising tool. It could help the client understand the issues faced in the project and giving the client an opportunity to access the project performance. The project personnel also said that visualizing the issues would help them make better decisions as they had a perceived vision of the findings before, but now they have factual data. They liked how using this dashboard, they could identify the areas where they are having the issues or understand why they are going wrong. And this would help them prioritize their time on different issues and make better decisions.  Identify UsersFind the Decision Makers within the User GroupDiscuss initial concept with the user groupDevelop PrototypeDashboardDiscussion with Decision makers to get feedback Development of Prototype Dashboard Evaluation of Prototype Dashboard Selection of User Group 93  4.2.4.2 Self -Evaluation by Comparing with Previous Similar Works As a part of self-evaluation, we compared the visualizations developed against examples from the past. Based on previous studies, we know that visualizations of construction documents were developed to mostly to help access data (Mao et al., 2007, Opitz et al., 2014 and Hu et al., 2016). In the dashboards developed in this study, using the different dimensions used to visualize the data, using the filter option, the document required can be found, or the search can be narrowed upon. Other researchers in the past who studied visualization of construction document data for visual analytics developed visualization techniques which limited the visualization to single view which led to the concentration of a large amount of data into a small space (Korde et al., 2005, Russell et al., 2009). Using the visualization technique suggested by this study, multiple coordinated views can be developed which gives more flexibility to the user and improves the understandability of the study. Hence, we can say that the visualization approach used in this study looks promising to the industry, has potential benefits to offer to the construction project team and offers more flexibility to the user when compared with visualizations developed in the past studies.  4.3 Challenges Relying on manual analysis resulted in huge work load as in the case of Project A or analysis of only a small fraction of the database as in the case of Project B. Hence, there is a need to move this from manual analysis and to extract and generate the excel spreadsheet with very little human intervention. But there are few challenges we came across to achieve this: • As seen in Project B mostly, there is a lack of uniform RFI format across different project participants which makes it difficult for a computer-based tool to extract information.  94  • Another significant issue which was observed in both the cases was the issue of incomplete data. Since the construction project teams must stick to strict deadlines and schedules, sending out the RFI becomes the primary focus even though it does have all the complete information in it. 4.4 Suggestion In order to overcome these challenges and generate structured RFI dataset with very little manual transformation, we suggest using the following fillable PDF RFI template shown in Figure 4.33. We developed this PDF RFI template because PDF files are the common type of file format used by the project members to generate and transfer RFI’s. We integrated the framework developed in the first phase of this study in the form of drop-down fillable blanks which makes it very easy to extract all the data from the RFI document into an excel spreadsheet. The template was also based on The Canadian Handbook of Practice for Architects, AIA Best Practices, and few other research studies on RFI’s (Hughes et al., 2013, Hanna et al., 2012) done in the past. This will also reduce manual entry which was being employed in the case of Project B to maintain the RFI log. 95   Figure 4.33: Snapshot of Proposed Request for Information Template (PDF Form) If this template is used, then the transformation of data would not require manual interpretation and hence would reduce the time spent on data transformation. It also has potential to reduce the problem of incomplete data as it makes it easier for the RFI writer to just select from the drop-96  down list and fill the form. Hence, we suggest using the following workflow to develop interactive RFI management dashboard for construction projects (Figure 4.34)97   Figure 4.34: Proposed Approach to Visualize Information in Request for Information98  Chapter 5: Conclusion 5.1 Summary In this study, we investigated the potential of data visualization techniques to address project delivery issues. But first, we had to overcome the challenge of unstructured nature of data content in Request for Information documents. After a thorough and iterative process of manually analyzing the RFI documents from two case studies, we developed a framework to structure and organize the data in RFI documents. In this framework, we have identified several quantitative and qualitative dimensions like time (when), spatial context (where), actor (who), reason(why), RFI Type, Domain, Property, Attribute, Entity (what) that can be used to visualise the data for analysing the information in the RFI’s. After extracting the textual data in the RFI documents, we developed Dashboards to visualize the information contained in RFIs using the current web-based data visualization software. Based on self-evaluation of the developed visualizations and learnings from past studies, we chose Interactive Dashboards as our tool to visualize and analyze the information extracted from the RFI documents. The RFI Dashboards were developed and evaluated with constant feedback from the industry personnel. The framework to structure RFI data and the dashboards developed to visualize the RFI data in this study had the following potentials among the many: • To evaluate the responsiveness the project participants • To identify the spatial concentration of issues in a project • To evaluate the reasons for the generation of the RFI’s  • To evaluate or compare the performance of projects • To better access RFI documents using filter options to search for documents 99  But, during the analysis we faced the following two problems which made manual extraction of data from the RFI’s tedious: • lack of a common format for RFI document within a project • the incomplete and massive size of the data To overcome these challenges, we developed an RFI template that would reduce the manual effort required for data transformation. With this study, we wanted to investigate if RFI data can be visualized and visualization of RFI data had some potential benefits to offer to project team members. And we observed that once the data in the RFI documents are structured and organized, it can be visualized and the visualization developed is promising. Hence we suggest that more studies should be conducted: • to develop the visualization environment for visualizing RFI data,  • to identify what information should be visualized to offer the maximum benefits,  • who should manage or have access to the information and so on. 5.2 Limitations and Future Work For this study, datasets from only two case studies were analyzed which we understand is a limitation to the study and not all RFI’s were analyzed from Project B. And in both these cases, we did not have access to the cost and schedule impact of the RFI’s which is one of the common variables used by past researcher’s in their study of RFI’s. To help us automate the analysis, we proposed an RFI template in a PDF format which is the type of communication document file format used by these projects studied for this research study. In this template, we incorporated the framework developed by us in this study along with the information which is mentioned as a requirement in many past literature.  Due to time constraint for this study, we could not test and 100  evaluate the use of this in a real project setting and observe how employing this would help the project team in decision making and RFI management.  Hence this study just acts as a test to investigate if visualization of information in RFI’s has benefits to offer to the construction industry, and we suggest that more studies should be conducted in the future to expand on this work.   101  Bibliography Alshawi, M., and Ingirige, B. (2003). “Web-Enabled Project Management: An Emerging Paradigm in Construction.” Automation in Construction, 12(4), 349–364. Andrews, B. W. (2005). “Modern Steel Construction: RFI Recommendations.” American Institute of Steel Construction, 45. Assaf, S. A., AI-Khalil, M., and AI-Hazmi, M. (1995). “Causes of Delay in Large Building Construction Projects.” Journal of Management in Engineering, 11(2), 45–50. Barlish, K., and Sullivan, K. (2012). “How to measure the benefits of BIM — A case study approach.” Automation in Construction, 24, 149–159. Brazee, A. (2014). “The Anatomy of a Request for Information (RFI).” [WWW Document]. URL https://jobsite.procore.com/the-anatomy-of-a-request-for-information-rfi. (18 April, 2017). Burns, T. M. (2005). “The Significance of Request for Information Factors on Steel Fabrication Duration.” Proceedings of the North American Steel Construction Conference. Burns, T. M. (2007). “The Effect of Selected Request for Information Variables on Steel Fabrication Outcomes.” Card, K. S., Mackinlay, J. D., and Shneiderman, B. (1999). Readings in Information Visualization: Using Vision to Think. Morgan Kaufmann. Cavka, H., Staub-French, S., & Poirier, E. A. (2016). (In publication) Developing Owner Information Requirements for BIM-enabled Project Delivery and Asset Lifecycle Management.  Chin, C., and Russell, J. S. (2008). “Predicting the Expected Service Level and the Realistic 102  Lead Time of RFI Process Using Binary Logistic Regression.” Proceedings 24th Annual ARCOM Conference, 739–748. Chiu, C., and Russell, A. D. (2007). “Construction Process Data Plus Visualization Tools Equals Performance Insights.” Construction Research Congress, ASCE, Freeport, Bahamas. Chiu, C, and Russell, A.D. (2011). “Design of A Construction Management Data Visualization Environment : A Top–Down Approach.” Automation in Construction, 20 (4), 399-417. Dainty, A., Moore, D., and Murray, M. (2006). Communication in Construction: Theory and Practice. Taylor & Francis, Oxon. Deutsch, R. (2015). Data-Driven Design and Construction : 25 Strategies for Capturing, Analyzing and Applying Building Data. Wiley. Gallaher, M. P., Alan, C. O. C., Jr Dettbarn, J. L., and Gilday, L. T. (2004). Cost Analysis of Inadequate Interoperability in the U . S . Capital Facilities Industry. Hanna, A. S., Ph, D., Asce, F., Tadt, E. J., Whited, G. C., and Asce, M. (2012). “Request for Information : Benchmarks and Metrics for Major Highway Projects.” 138(2), 1347–1352. Hobbs, Jon, National Practice Program, and Royal Architectural Institute of Canada. 2009. Canadian Handbook of Practice for Architects. 2nd edition. Ottawa: Royal Architecture Institute of Canada. Hsieh, H.-F., and Shannon, S. E. (2005). “Three Approaches to Qualitative Content Analysis.” Qualitative Health Research, 15(9), 1277–1288. Hu, K., Staub-French, S., Tory, M., and Nepal, M. P. (2016). “Visarchive : A Time and Relevance Based Visual Interface For Searching, Browsing, and Exploring Project Archives.” Visualization in Engineering, 4(1). Hughes, N., Wells, M. S., Nutter, C., and Zack, J. G. (2016). Impact & Control of RFIs on 103  Construction Projects. Navigant. Kerzner, H. (2013). Project Management Metrics, KPIs, and Dashboards: A Guide to Measuring and Monitoring Project Performance. Wiley. Korde, T., Wang, Y., and Russell, A. D. (2005). “Visualization of Construction Data.” Proceeding of the 6th Construction Specialty Conference. Kuo, C. H., Tsai, M. H., and Kang, S. C. (2011). “A Framework of Information Visualization for Multi-System Construction.” Automation in Construction, 20(3), 247–262. Landis, J. Richard, and Gary G. Koch. 1977. The Measurement of Observer Agreement for Categorical Data. Biometrics 33 (1): 159-74. Lasswell, Harold D. 1948. Power and Personality. New York: Viking Press. Love, P. E. D., Zhou, J., Sing, C., and Kim, J. (2014). “Assessing the Impact of RFIs in Electrical and Instrumentation Engineering Contracts.” Journal of Engineering Design, 25(4–6). Maheshwari, D., and Janssen, M. (2014). “Dashboards for Supporting Organizational Development : Principles for The Design and Development of Public Sector Performance Dashboards.” Proceedings of the 8th International Conference on Theory and Practice of Electronic Governance, 178–185. Mao, W., Zhu, Y., and Ahmad, I. (2007). “Applying Metadata Models to Unstructured Content of Construction Documents : A View-Based Approach.” Automation in Construction, 16, 242–252. Miles, M. B., Huberman, A. M., and Saldana, J. (2013). Qualitative Data Analysis a Methods Sourcebook. Sage Publication. Mohamad, S., Tilley, P. A., and Tucker, S. N. (1999). “Quantifying the Time and Cost 104  Associated with the Request for Information (RFI) Process in Construction.” International Journal o f Construction Information Technology, 7(1), 35–50. Opitz, F., Windisch, R., and Scherer, R. J. (2014). “Integration of Document and Model-Based Building Information for Project Management Support.” Creative Construction Conference, 403–411. Pauwels, K., Ambler, T., and Clark, B. (2009). “Dashboards as a Service Why, What, How, and What Research is Needed?” Journal of Service Research, (2), 175–189. Philips-ryder, M., Zuo, J., and Jin, X. H. (2013). “Evaluating Document Quality in Construction Projects – Subcontractors ’ Perspective.” International Journal of Construction Management, 77–94. Rasmussen, N. H., Bansal, M., and Chen, C. Y. (2009). Business Dashboards : A Visual Catalog for Design and Deployment. Wiley. Rojas, E. M., and Lee, N. L. (2007). “Visualization of Project Control Data: A Research Agenda.” Computing in Civil Engineering. Russell, A. D., Chiu, C.-Y., and Korde, T. (2009). “Visual Representation of Construction Management Data.” Automation in Construction, Elsevier B.V., 18(8), 1045–1062. Russell, A. D., and Udaipurwala, A. (2000). “Assessing the Quality of a Construction Schedule.” Proceedings of the Sixth Construction Congress, 928–937. Shaaban, S., Lockley, S., and Elkadi, H. (2001). “Information Visualisation for the Architectural Practice.” Proceedings of the IEEE Fifth International Conference on Information Visualization. Shim, E., Carter, B., and Kim, S. (2016). “Request for Information ( RFI ) Management : A Case Study.” 52nd ASC Annual International Conference Proceedings. 105  Shneiderman, B. (1996). “The Eyes Have It : A Task by Data Type Taxonomy for Information Visualizations.” Proceedings 1996 IEEE Symposium on Visual Languages, 336–343. Song, K., Pollalis, S. N., and Pena-mora, F. (2005). “Project Dashboard : Concurrent Visual Representation Method of Project Metrics on 3D Building Models.” Computing in Civil Engineering. Song, L., Asce, M., Mohamed, Y., Asce, M., Abourizk, S. M., and Asce, M. (2009). “Early Contractor Involvement in Design and Its Impact on Construction Schedule Performance.” Journal of Management in Engineering, (January). Songer, A. D., Hays, B., and North, C. (2004). “Multidimensional Visualization of Project Control Data.” Construction Innovation, 4, 173–190. Songer, A. D., and Molenaar, K. R. (1996). “Selecting Design-Build : Public and Private Sector Owner Attitudes.” Journal of Management in Engineering, 12(6), 47–53. Staub-French, S., Russell, A., and Tran, N. (2008). “Linear Scheduling and 4D Visualization.” Journal of Computing in Civil Engineering, 22(3), 192–205. Thorpe, B. T., and Mead, S. (2001). “Project-Specific Web Sites : Friend or Foe?” Journal of Construction Engineering and Management, 127(5), 406–413. Tilley, Paul. (1997). “Causes, Effects and Indicators of Design and Documentation Deficiency.” Proceedings of the First International Conference on Construction Industry Development: Building the Future Together, 2:388–95. Tilley, P., Wyatt, A., and Mohamed, S. (1997). “Indicators of Design and Documentation Deficiency.” Proceedings of the Fifth Annual Conference of the International Group for Lean Construction, 137–148. Yin, R. K. (2013). Case Study Research : Design and Methods. Sage Publication. 106  Zainal, Z. (2007). “Case Study as a Research Method.” Jurnal Kemanusiaan, 9.                 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

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"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.24.1-0344010/manifest

Comment

Related Items