A PILOT STUDY OF WEB-BASED INFORMATION BOTTLENECK IDENTIFICATION IN AEC PROJECTS By NISHCHHAL NIHAL PANDEY A THESIS Submitted to Michigan State University in partial fulfillment of the requirements for the degree of Construction Management – Master of Science 2022 ABSTRACT A PILOT STUDY OF WEB-BASED INFORMATION BOTTLENECK IDENTIFICATION IN AEC PROJECTS By Nishchhal Nihal Pandey The success of the Architecture, Engineering, and Construction (AEC) project relies heavily on the effective communication and information exchange between project team members. A prominent reason for delays and progress shortcomings in AEC project teams is information bottlenecks, defined as missing project information bits which can be due to large influx of information or inadvertent withholding of information at a particular time. Information and communication exchange patterns between project team members shed a light on the possible occurrence of information bottlenecks. Therefore, the research question this research aims to answer is “Can the usability and adaptability of information bottleneck prediction in AEC projects be improved through a web- based tool?” The web-based platform is designed to cater the specific information exchange trends in a typical project. Providing visual representations, and explanations further ease the understanding of the root issue. Finally, through two expert interviews, the web tool is revised, and final tool is presented, and future directions of work are discussed. ACKNOWLEDGEMENTS This thesis is the result of the confidence placed in me by my advisors Dr. Sinem Mollaoglu, and Dr. Dong Zhao. Two years ago, I was offered the great opportunity to practice research by my advisors and that opened the door to pursue this exciting research. Over the past couple of years, I have received unwavering support and guidance from my advisors and for that I am extremely grateful. I would also like to thank my thesis committee member Dr. Kenneth Frank for his support and ideas which helped to make this thesis better. I am thankful to National Science Foundation (NSF) for their supplemental grant which helped me to learn and grow in the field I always wanted to explore. I am thankful to Karim and the Venturit team, I really enjoyed exploring the field of software engineering through my internship. I am thankful to my parents Geeta and Sudhir, my late grandma Nirmala for steadily helping me in my journey through graduate school. I would like to recognize the help and support of my uncle Brijendra, and my aunt Vaishali, as well. I am thankful to the CM faculty at MSU, including Professor Mrozowski, Dr. El-Gafy, Dr. Berghorn, and Dr. Syal for their constant help and assistance throughout my graduate studies. I was extremely fortunate to have an excellent group of co-researchers in the IOPT4 team. I am thankful to Meltem, Dr. Joseph, Dr. Garcia, Hassan, and Nishchay for their consistent advice and support throughout my graduate research. Lastly, I would like to thank the amazing new friends I made through this journey and my friends back home for always been supportive through ups and downs. Nitesh, Josh, Terry, iii Greta, Rishabh, Divyansh, Divyanshu, Prabhat, Ankit, Anuvrat, Maitraiya, Kelton, Sal, Saad, Ahamed, Bhushan, and Amar, I appreciate you all. iv TABLE OF CONTENTS LIST OF TABLES……………………………………………………………………………………………………………………………………...vii LIST OF FIGURES…………………………………………………………………………………………………………………………………...viii CHAPTER 1 INTRODUCTION…………………………………………………………………………………………………………….….……1 1.1 BACKGROUND…………………………………………………………………………………………………………………..….1 1.2 PROBLEM STATEMENT………………………………………………………………………………………………..………..2 1.3 RESEARCH GOAL AND OBJECTIVES……………………………………………………………………………………..…3 1.4 RESEARCH DESIGN……………………………………………………………………………………………………………..…4 1.5 SCOPE AND LIMITATIONS……………………………………………………………………………………………………..6 1.6 DELIVERABLES………………………………………………………………………………………………………………………7 CHAPTER 2 LITERATURE REVIEW………………………………………………………………………………………………..……………8 2.1 INFORMATION EXCHANGE IN AEC PROJECT TEAMS………………………………………………..…………….8 2.2 LEAN THEORY AND BOTTLENECKS………………………………………………………………………….…………….10 2.3 BOTTLENECKS IN AEC PROJECTS………………………..………………………………………………………………..13 2.3.1 BACKGROUND OF PROJECT BOTTLENECKS……………………………………………………….….13 2.3.2 BOTTLENECK METRICS….…………………………………….…………………………………………….…15 2.4 INFORMATION EXCHANGE PLATFORMS……………………………………………………………….………….17 2.5 ISSUE TYPES TO INFORM BOTTLENECK CALCULATIONS………………………………………………………..21 2.6 MACHINE LEARNING AND AUTOMATION IN BOTTLENECK DETECTION…………………………………22 2.7 USABILITY INSPECTION OF WEB-TOOLS……………………………………………………………………………….24 2.8 SUMMARY…………………………………………………………………………………………………………………………..27 CHAPTER 3 METRICS REVISITED……………………………………………………………………………………………………………..28 3.1 MODIFIED BOTTLENECK METRICS………………………………………………………………………………………..28 3.2 PRODUCTIVITY AND ISSUE RESOLUTION SPEED……………………………………………………………………31 3.3 BOTTLENECKS METRICS AND ACTIVITY TYPES………………………………………………………………………32 3.4 SUMMARY…………………………………………………………………………………………………………………………..33 CHAPTER 4 METHODOLOGY…………………………………………………………………………………………………………………..34 4.1 INTRODUCTION…………………………………………………………………………………………..…………………..….34 4.2 RESEARCH GOALS AND OBJECTIVES……………………………………………………………………….…………….34 4.3 RESEARCH APPROACH AND SCOPE……………………………………………………………………………………..35 4.4 RESEARCH METHODOLOGY…………………………………………………………………………………………………36 4.5 DATA COLLECTION AND PROCESSING………………………………………………………………………………….40 4.5.1 EMAIL EXCHANGE DATA………………………………………………………………………………………42 4.5.2 PROJECT DOCUMENTATION DATA……………………………………………………………………….44 4.5.3 MEETING MINUTES DATA…………………………………………………………………………………….49 4.5.4 PROGRESS LOOPS AND INTERVALS……………………………………………………………………….50 4.5.5 WEB-BASED TOOL………………………………………………………………………………………………..53 4.6 USABILITY INTERVIEWS……………………………………………………………………………………….……………….54 4.6.1 BOTTLENECK REPORTING TAB……………………………………………………………………………..54 4.6.2 INFORMATION FLOW OF THE PROJECT……………………………………………………………….56 4.6.3 BOTTLENECK PREDICTION AND POTENTIAL REMEDIES………………………………………..59 v 4.7 RESEARCH QUALITY…………………………………………………………………………………………………………….61 4.7.1 ITERATIVE RELIABILITY FOR DETERMINING THE TYPE OF ISSUES…………………….……61 4.7.2 DEVELOPMENT OF PROTOCOL FOR ISSUE TYPES…………………………………………………62 4.8 SUMMARY…………………………………………………………………………………………………………………………..63 CHAPTER 5 RESULTS……………………………………………………………………………………………………………………………….64 5.1 INTERVIEW FINDINGS………………………………………………………………………………………………………….64 5.2 INTERVIEW FEEDBACK AND MODIFICATIONS IN THE TOOL………………………………………………….67 CHAPTER 6 CONCLUSIONS AND DISCUSSIONS………………………………………………………………………………………..72 6.1 INTRODUCTION……………………………………………………………………………………………………………………72 6.2 KEY FINDINGS………………………………………………………………………………………………………………………72 6.2.1 USABILITY AND ADAPTABILITY OF THE TOOL……………………………………………………….72 6.3 RESEARCH CONTRIBUTIONS…………………………………………………………………………………………………73 6.4 LIMITATIONS……………………………………………………………………………………………………………………….74 6.5 DIRECTION FOR FUTURE RESEARCH……………………………………………………………………………………..75 6.6 CONCLUSION……………………………………………………………………………………………………………………….76 APPENDIX………………………………………………………………………………………………………………………………………………77 APPEXDIX A: INTERVIEW PROTOCOL…………………………..……………………………………………………………78 APPENDIX B: PHYTHON CODE……………………………………..…………………….…………………………………….82 APPENDIX C: INTERVIEW FINDINGS…………………………………………………..……………….……………………..97 APPENDIX D: EMAIL CLEANING PROTOCOL……………………….…………………………………………………….100 APPENDIX E: IRB APPROVAL LETTER…………………………………………………….……………………...………….102 APPENDIX F: EXAMPLE OF IDENTIFICATION OF ISSUE TYPES…………………………………….……………..107 REFERENCES…………………………………………………………………………………………………………………………………..…… 110 vi LIST OF TABLES TABLE 2.1.2: INFORMATION EXCHANGE AND THEIR ADVANTAGES AND DISADVANTAGES……………………10 TABLE 2.1.3: TRACK OF RESEARCH AND BOTTLENECKS……………………………………………..…………………………..12 TABLE 2.5: REVIEW OF CONSTRUCTION MANAGEMENT WEB-BASED TOOLS CURRENTLY IN USE…………………………………………………………………………………………………………………………………….………………….20 TABLE 2.7.2: LITERATURE REVIEW ON USABILITY SURVEY……………………………………………………………………..26 TABLE 3.1: KEY DIFFERENCES BETWEEN ORIGINAL AND MODIFIED METRICS………………………………………..30 TABLE 4.2: RESEARCH OBJECTIVES AND METHODS……………………………………….…………………..………………….34 TABLE 4.5: ARCHIVAL DATA TYPE, AND DATA PROCESSING…………………………………….……………………….……41 TABLE 4.5.1: SAMPLE CLEANED FILE TO STUDY THE NUMBER OF INFORMATION IN FORM OF ATTACHMENTS SHARED BETWEEN TEAMS……………………………………………………………..…………………………….43 TABLE 4.5.2: TYPE OF INFORMATION SHARED IN UNIFIER AND PLANGRID…………………….……………………..45 TABLE 4.5.4: PYTHON LIBRARIES AND THEIR FUNCTIONS……………………………………………..………………………54 TABLE 4.6: QUALITATIVE ASSESSMENTS AND SECTION DESCRIPTIONS……………………..………………………….61 TABLE 6.3: COMPARISON BETWEEN INITIAL AND FINAL SCREENSHOT OF THE WEB-BASED TOOL……………………………………………………………………………………..………………………………………………………………67 vii LIST OF FIGURES FIGURE 1.4: RESEARCH DESIGN FOR IDENTIFICATION OF BOTTLENECKS………………………………………………….5 FIGURE 2.2: FORMS OF INFORMATION EXCHANGE IN PROJECT TEAMS…………………….…………….………………9 FIGURE 4.4: RESEARCH METHODOLOGY………………………………………………………………..…………………..………….38 FIGURE 4.5.1: SAMPLE RAW UNCLEANED EMAIL FILE……………………………..................................................43 FIGURE 4.5.1.2: FUNCTIONS DEVELOPED TO IMPORT THE EMAIL EXCHANGE DATA IN THE CODE……..….44 FIGURE 4.5.2: CLEANED PROJECT DOCUMENTATION DATA…………….……………………………………………….……47 FIGURE 4.5.2.2: DETAILS OF THE CODE USED FOR INFORMATION EXTRACTION FROM DOCUMENTATION WEBSITE………………………………………………………………………………………………………………………………………………..48 FIGURE 4.5.3: FORMATTED MEETING MINUTES DOCUMENT………………………………………………………………. .49 FIGURE 4.5.4: CODE TO EXTRACT MEETING MINUTES ISSUES FROM THE EXCEL DOCUMENT………………..53 FIGURE 4.6.1: SNAPSHOT OF THE BOTTLENECK REPORTING PAGE………………………………………………..………55 FIGURE 4.6.1.2: SNAPSHOT OF THE DV AND WIP CONDITIONS TO REPORT ON POSSIBLE BOTTLENECKS……………………………………………………………………….……………………………………………………………….55 FIGURE 4.6.2: SNAPSHOT OF INFORMATION EXCHANGE PAGE IN THE WEB-TOOL……………….……………….58 FIGURE 4.6.2.2: SNAPSHOT OF AVERAGE DAYS TO RESOLVE PAGE IN THE TOOL……………………………………58 FIGURE 4.6.2.3: SNAPSHOT OF THE PRODUCTIVITY PAGE IN THE TOOL…………………………………………………59 FIGURE 4.6.3: SNAPSHOT OF THE BOTTLENECK PREDICTION/ POTENTIAL REMEDIES………………………….…59 FIGURE 4.7: DESIGN AND THE RE-DESIGN QUALITATIVE ASSESSMENTS OF THE TOOL……………………..……60 FIGURE A: INFORMATION EXCHANGE AND ISSUES INFORMATION……………………………………………………….80 FIGURE B: AVERAGE DAYS TO COMPLETE AND PRODUCTIVITY………………………………………………………………80 FIGURE C: PYTHON CODE ………………………………………………………………………………………………………………………82 viii CHAPTER 1 INTRODUCTION 1.1 BACKGROUND Process improvement, waste and rework reduction, efficiency improvement form the core values of the lean philosophy (Abdelhamid 2007). Large scale construction projects rely heavily on information exchange throughout their delivery. Information exchange can be in form of emails, through meetings, information exchanged via project documentation data (Sacks 2007). Given the amount of information that is shared between team members there remains a chance of possible wastage, and rework. This may lead to the occurrence of possible information bottlenecks. Lean Construction Organization defines bottlenecks in manufacturing as follows: “A bottleneck (or constraint) in a supply chain means the resource that requires the longest time in operations of the supply chain for certain demand.” Sacks (2010) explains information bottlenecks in construction as the withholding of project related information by team members which might result in delays in potential delays in cost and schedule. The success of Architecture, Engineering, and Construction (AEC) projects relies heavily on the effective communication, and information exchange between project team members. Turbulent information exchange can be due to a variety of personal or organizational issues. The concept of Bottlenecks in AEC teams was first introduced using the Fluid Mechanics concepts by the works of Fyall (2002). Over successive years, research has focused on using the fluid mechanics elements to define the occurrence of information or project bottlenecks in project teams. Information Bottlenecks is defined as One such issue is information bottleneck, defined as withholding or missing bits of project information. Bottlenecks both in planning and execution phases of the project have the tendency to cause schedule delays and cost overruns. 1 Information and communication exchange patterns between project team members sheds a light on the possible occurrence of bottlenecks. This thesis aims to contribute to the existing body of knowledge by studying if the existing prediction technique of information bottlenecks can be improved by integrating lean principles and implementing them through a web-based tool. Recent literature surrounding bottlenecks involved prediction through identification of key information and performance indicators by studying the information flow between teams. This thesis uses similar approach by identifying key performance indicators (KPIs) using archival data of two large scale expansion projects. The model was implemented using a web-based platform using python coding. After development, expert interviews were conducted to get the feedback on the usability and adaptability of the tool in actual AEC projects. Feedbacks received during these interviews were incorporated in the model, and the modified model will be presented for the readers. 1.2 PROBLEM STATEMENT Bottlenecks in information flow is important to track progress in AEC projects. Despite a number of prior research efforts on this important topic in the literature adapting quantitative, qualitative, and mixed methods, there still is a gap in identification techniques which can readily applied to most construction projects. The issue of implementation can be explained by the complexity of some of the equations used. The inputs for the equations which are used for quantifying information metrics are rather complex and require rigorous calculations. The problem related to the usability therefore needs to be addressed for prediction of bottlenecks in AEC projects. 2 1.3 RESEARCH GOAL AND OBJECTIVES The research goal is to develop a web-based platform tool and test its usability and adaptability to predict information bottlenecks in AEC Projects. The research objectives are to: 1. Determine and adjust key performance indicators and efficiency metrics to quantify information exchange trends between team members during project delivery: Difficulty in calculation of existing metrics in literature was addressed by making suitable modifications in these metrics. The modified metrics were then used to quantify metrics based on the available documentation data. These metrics include information development velocity (DV), productivity, average days to resolve project issues, work in progress (WIP) (Sacks 2011). 2. Adopt activity types (i.e., Pooled, Sequential, Reciprocal, and Intensive) based on their collaboration requirements (Bell and Kozlowski 2019) and explore their impacts on bottlenecks to further improve bottleneck predictions during project delivery. 3. Using data from two existing case study projects, test the metrics developed in Objectives 1 and 2 above. This step was completed by the research team, funded by NSF CMMI # 1825678 and IIS# 1928278, that the author of this thesis was a part of. The research team developed a predictive model for information bottlenecks based on information publication data to: (a) predict information bottleneck using information publication data that are practically feasible to estimate and (b) study the effect of activities with different interdependencies on the predictive model performance. at study 4. Applying the model and results developed in Step 3 above, design a web-based tool to test the usability and adaptability of bottleneck prediction. The web-based tool will help for easier execution of large-scale project data, capturing important project related information. Email 3 exchange data, meeting issues, project documentation data will be imported to the web-based tool, and it can also be used to generate graphical reports of information trends and monthly KPIs. The web-tool developed was iteratively improved using the following steps: • The tool was presented to and allowed to be navigated by two industry specialists. Their feedback and comments were recorded by the researcher. Furthermore, the feedback were studied to understand if the tool can be used in AEC teams, who should use the tool, what improvements should be made in the tool to make it better. • The feedback received was implemented in the tool and the final tool is presented in this thesis. 1.4 RESEARCH DESIGN Adoption of bottleneck metrics from the literature, automation challenges, development of a web-based interface using data from two case studies, and expert interviews for verification and further development are the four main areas of the study. Quantitative and qualitative methods to address these scopes were adopted in the study design. The research is divided into four separate sections with different deliverables by the researcher. • Section 1: Developing quantification metrics and modifying information metrics formulas to quantify team performance and project performance. • Section 2: Automating the metrics and using the project documentation raw data to report on possible information bottlenecks. 4 • Section 3: Developing a web-based used using python coding and reporting on bottlenecks. • Section 4: Interviewing industry experts to get their feedback on the adaptability and usability of the tool. Figure 1.4 explains the automation part and conversion of meeting minutes data, documentation data to identify bottlenecks, and is divided into 4 sections as mentioned above FIGURE 1.4: RESEARCH DESIGN FOR IDENTIFICATION OF BOTTLENECKS 5 1.5 SCOPE AND LIMITATIONS The scope of the research focuses on information exchange between AEC project team members. Complex AEC projects require collaboration between a number of teams including owner, designer, contractors, and sub-contractors. Such a level of collaboration involves extensive information and communication exchange. Therefore, the means through which most communication and information exchange between teams takes place are shortlisted and analyzed. These means include email communication, web-based documentation, and face to face resolution through bi-weekly meetings. To aid with the applicability, a web-based tool that utilizes improved methods based on the literature and ML is designed to track, identify information sharing patterns between AEC project team members, and detect bottlenecks in reliable and practical manners. The web-based tool will be trained to accept information data and use performance metrics and information trends to predict possible occurrence of bottlenecks. The prediction accuracy will be further tested using a case study data from a third project. This research effort thus aims to answer the research question, “Can the adaptability and accuracy of information bottleneck prediction in AEC projects be improved through a web-based tool?” Therefore, this thesis aims at providing more reliable, applicable, and easier identifiable techniques of finding bottlenecks by using the following methodologies: • Reviewing and modifying metrics defined in literature; • Using dash framework to identify and report on existing information bottlenecks; • Designing a web-based platform to implement the model; and • Verifying and further improving the web-based interface through expert interviews. 6 1.6 DELIVERABLES The key deliverables targeted through this effort include development of improved performance indication metrics to measure efficiency of information usage, design of a web-based platform to help with easier implementation of these metrics in complex projects and to test the accuracy of the prediction using a case study dataset. The key deliverables are discussed in the points below and the figure highlights key input and output for this study. i. Key performance indicators and efficiency metrics to quantify information trends between project teams. Discussions on which metrics require rigorous calculations based on literature and modifications made to equations. ii. Project issues characterization into pooled, sequential, reciprocal, and intensive. iii. Web-based platform to predict bottleneck using the lessons learned from analysis that is ready for beta version. 7 CHAPTER 2 LITERATURE REVIEW Through this section the researcher discusses the advancements in research in the field of project bottlenecks over the years. The section is divided into 4 major sections discussing what bottlenecks in AEC projects, information exchange platforms used by teams which are useful in identifying some of these issues, some of the web-based tool already available to help in identification, and a summary section. 2.1 INFORMATION EXCHANGE IN AEC PROJECT TEAMS AEC teams rely on coordination, communication, and participation between team members of diversified backgrounds for the success of the project. AEC teams maybe chose to transfer information and project related data to their project teams and other partners participating in the projects, such technologies can be termed as Information Exchange (Baldwin et. al 1999). Information can be characterized in several different types based on their usage. From purchase orders, request for information (RFI), bill clarifications to minor clarifications or corrections in the drawing sets (Journal of Institution of Civil Engineers). Substantial savings in cost can be achieved if information management for a project is well defined. The following figure discusses the types of data exchange between project team members. 8 Email •For Clarifications about Exchange Data drawings or issues. •Sharing of project drawings BIM Exchange for clarifications •All other forms of Project documentation are usually Documentation Data Exchange shared through web based platforms FIGURE 2.2: FORMS OF INFORMATION EXCHANGE IN PROJECT TEAMS Trends of information exchange can be used to predict how distributed or smooth knowledge transfer is in AEC Project Teams. Such trends also have possible implications on bottlenecks. The information and knowledge which is marked by peaks and valleys meaning when information is exchanged in bulks at one point of time can have impacts on the productivity and efficiency of teams. Such turbulent information exchange can lead to the occurrence of project bottlenecks. Information provided at the right time and consistently through communication or information exchange platforms leads to a more coherent knowledge transfer. Sacks (2007, 2009, 2010a, 2010b, 2011) highlights how team members interact when it comes to sharing project related information. Sacks (2007) explained that information exchange between team members occurs in three major forms: Through project documentation websites, emails, and face to face interactions in meetings. There are several perks attached to each type of 9 information exchange they are discussed in Table 2.1.2 as adapted from Foley and Macmillan (2005). TABLE2.1.2: INFORMATION EXCHANGE AND THEIR ADVANTAGES AND DISADVANTAGES Type of Information Exchange Advantages Disadvantages Email Exchange • Easier to use • Record might not be maintained • Specific recipients can be set • Makes it harder for PM to track • Takes minimal time progress • May result in loss of data • Not ideal for RFIs, Change orders Project Documentation • Data can be archived and saved for future • Might not be adoptable equally by all references team members • Provides insights and reduces conflicts • Takes more time than emails • Suitable for large or bulk files • Not suitable for minor clarifications Meetings • More feasible for on spot clarifications • Requires in-person presence • Suitable for on minor clarifications • Preferred for hard documents Sacks (2010a) highlighted how certain trends in formation exchange is capable of indicating the type of information exchange patterns between members. A turbulent information exchange marked by peaks and valleys reflects that information is shared in bulks, the chances of occurrence of bottlenecks in such cases is higher (Ashwini et. al. 2012). 2.2 LEAN THEORY AND BOTTLENECKS Over the years, several efforts have been made to understand and predict bottlenecks in AEC industry. The rather innovative findings of Fyall (2002) opened an uncharted territory in the field 10 of project bottleneck identification. Over the years several qualitative and quantitative approaches have been pursued by researchers to come up with optimum prediction techniques. Contributions of Tribelsky and Sacks (2007, 2010, 2011) have been note-worthy . The learnings and prediction tools discussed through the works of Sacks prompted to the question whether these methodologies can be realistically applied in an AEC project. The direction chosen to answer this question revolved around adaptability of the produced methods. The easier and more user friendly the implementation, the easier it is to adapt. This prompted to the research question “Can the adaptability and accuracy of bottleneck prediction in AEC projects be improved by the use of machine learning concepts through a web-based platform?”. Quantification metrics and KPIs used to quantify information exchange have been the main area of research when it comes to prediction of bottlenecks. Staron and Meding (2011), developed a unique software platform using lean principles by conducting a case study at a software development unit and successfully identified one bottleneck in the design phase. Although this approach pioneered the use of software technology in identifying project bottlenecks, it has not been used by construction firms due to the lack of application software and its limited sample of implementation. Inspired by the metrics developed by Tribelsky and Sacks (2010a), Hattab and Hamzeh (2018) developed a mathematical model to calculate DV and WIP but did not use it for bottleneck resolution. The literature illustrates the emphasis on development of KPIs and quantification metrics to understand how information is shared between project teams. Staron and Meding (2011), however, is striking in the sense it incorporates identification through software development. This kind of approach can be used as a benchmark for this work as it aims to contribute by using 11 machine learning tools for bottleneck prediction. Table 2.1.3 below highlights major developments and efforts in identifying construction bottlenecks over the years. TABLE 2.1.3: TRACK OF RESEARCH ON BOTTLENECKS Area of Research in Bottlenecks 2000-2005 2005-2010 2010-2015 2015-2020 Analogy drawn between fluid mechanics concepts of bottleneck flow and information bottlenecks. Fyall (2002) Fyall (2002), Use of fluid mechanics equations to Chang and explain the bottleneck phenomenon Ibbs(1999) Sacks et. al (2010), Tribelsky Understanding how information Tribelsky and and Sacks flow effects bottleneck occurrence Sacks (2007) (2010a) Tribelsky Development of quantification and Sacks metrics to predict bottlenecks (2010b) Use of qualitative approach and Tribelsky waste phenomenon to understand Sacks et. al Abdelhamid and Sacks wastage of information (2010) et.al (2009) (2011) Dainty Proposal of integrative approach et.al(2011) Development of software to Stewart and Staron and understand occurrence of Mohamed Meding bottlenecks (2004) (2011) Al Hattab Enhancing already defined and quantification terms to ease the Hamzeh calculation steps of metrics (2015) Use of tracking tool to understand if Wolniak reduction in wastage can improve Huang et. al Wolniak at. Al bottleneck calculation (2009) (2013) (2018) Comparison of results obtained Emmitt and through qualitative analysis with Gorse Zivaljevic quantitative analysis (2006) (2015) 12 2.3 BOTTLENECKS IN AEC PROJECTS A detailed review of the available literature for identification and prediction of bottlenecks highlights that the focus has been upon quantification and formulation of information trends patterns. With the works of Sacks and Tribelsky (2007, 2009, 2010a, 2010b, 2011), Whitford and Chang (1998, 2016) a great understanding has been developed on how exactly fluid mechanics concepts can be used as a reference to formulate equations. Some of the key metrics identified through their works are DV, WIP, Action Rate, Rework, Bottleneck. Although the inputs for these equations are complex and require complex data sets from different phases of the projects. These inputs are sometimes difficult to capture with the project documentation data available as information regarding exact workflow, time stamp of work, unused documents is very difficult for a large scale project. Therefore, this research aims to contribute to the existing lean literature by providing modifications on already identified metrics and increasing its usability by designing a web-based model. The use of reporting model for identifying the instance where the probability of bottleneck occurrence might also provide insights on a more accurate and reliable prediction. Bottlenecks in AEC projects could have possible implications on project cost and schedule. Therefore, it is important to understand and mitigate the reasons which might lead to the occurrence of such bottlenecks (Dainty et. al 2009). Through the following sub-section, the researcher discusses the prior literature efforts in this area. 2.3.1 BACKGROUND OF PROJECT BOTTLENECKS According to a global construction survey by KPMG in 2019, over 80% of all construction finish over time. This delay in construction projects can be attributed to a lot of factors including 13 ineffective communication, rework, poor planning, lack of coordination, and wastage. To address these issues, over the last decades, construction firms have increasingly shown proclivity towards adaptation of more sustainable forms of construction. Lean Construction is one such approach. Defined by Lean Construction institute as “Lean Construction extends from the objectives of a Lean production system—maximize value and minimize waste—to specific techniques and applies them in a new project delivery process” (IPD and Lean Construction, 2014) Effective communication and coherent project information exchange between multi-disciplinary project team members serve as the benchmark for the successful and timely completion of a construction project (Sacks et. al. 2010a). To achieve this, it is important to identify obstacles which adversely affect the success of a construction project. Withheld information by team members, termed as ‘bottleneck’ in lean literature, is one of the factors. Effective communication and coherent project information exchange between multi-disciplinary project team members serve as the benchmark for the successful and timely completion of a construction project (Sacks et. al. 2010b). To achieve this, it is important to identify obstacles which adversely affect the success of a construction project. Withheld information by team members, termed as ‘bottleneck’ in lean literature, is one of the factors which often results in unprecedented project outcomes including cost overruns and schedule delays (Tribelsky and Sacks 2011). The need to develop an ideal technique for precise bottleneck prediction to ensure smooth information transfer between teams and optimum productivity of team members were primary influences that drove this research. There are two different types of bottlenecks in AEC projects which can be explained through the literature. Information bottlenecks draws similarity from deep learning algorithms and whereas 14 Project bottlenecks uses fluid mechanics concepts to understand the potential issues in AEC teams. This research using the deep learning definitions of Information bottlenecks redefines information bottlenecks for AEC teams (Newvan et. al 2016). This section highlights why a more comprehensive and reliable approach is required. Based on the current research trends on quantifying information bottlenecks, there is a lack of a more adaptable techniques for bottleneck identification. Through the following sections, the researcher will discuss information exchange in project teams, lean theory and bottlenecks, metrics for identifying bottlenecks, issue types based on literature, and role of automation in construction industry. 2.3.2 BOTTLENECK METRICS In this section the researcher will focus on the different metrics defined for the quantification of information exchange. The section discusses the already developed metrics from prior literature efforts. Due to limitation and difficulty in extracting the exact information bits, some of these metrics have been redefined in chapter 3 of this thesis. The researcher also discusses the potential limitations of exactly implementing the metrics in the following section. • Development Velocity (DV)- Development velocity can be defined as the development of information as represented by the accumulation of details. It is calculated between two time intervals, and the first time interval is when project information is made available to project teams from the web-tool. The DV is defined by the following equation (Tribelsky and Sacks 2010a): DVt = (PSt - PSt1) / (Tt -Tt1) 15 DVt – DV at time T PS – Package size at time t and t1 T – Time interval at t and t1 Potential Limitation: In the research discussed above, the changes in the drawings is marked automatically. This makes tracking comments, and changes easier and hence calculation of package size is easier. The calculation of Package size used a software called Autovue which tracks changes and updates in the new drawing sets uploaded in the project documentation website. Since, the project involved in this research did not have an automated feature which tracks and counts number of changes made in each update, it is difficult to manually track these changes over the course of the project. • Package Size (PS) - Quantifies the level of detail of information package. The equation used for PS in literature is explained below (Tribelsky and Sacks 2010a): PSt= ∑ nIAv i PS – Package size at time t niAvi – number of attributes of an information package Potential Limitation: Package size calculation requires extensive marking and counting of each update or comment made in with each drawing update in the project. It can be done with certain software like Autovue automatically. However, since Autovue was not used for the projects used for this research, manual counting of each change requires extensive calculations. • Work in Progress (WIP) – The number of available but unused information packages. The equation used is discussed below (Tribelsky and Sacks 2010a): 𝑊𝐼𝑃 = ∑ 𝑛𝐼𝑃𝑗 𝑗 = 1 (𝑡 − 𝑇𝑢𝑝𝑗) 𝑃𝑆𝑗𝑈𝑗 16 WIP – Work in Progress 𝑃𝑆𝑗𝑈𝑗 − 𝑈𝑗 = 1 if package j has been viewed or downloaded by a team member 𝑇𝑢𝑝𝑗 – The day at which the package was uploaded. Potential Limitation: Package size calculation requires extensive marking and counting of each update or comment made in with each drawing update in the project. It can be done with certain software like Autovue automatically. However, since Autovue was not used for the projects used for this research, manual counting of each change requires extensive calculations. • Bottleneck Indicator (BN) – Bottleneck indicator is matrix developed by the works of Tribelsky and Sacks (2010a), where values of DV and WIP reflect on potential bottlenecks in a particular range. Bottleneck indicator reports 1 when WIP is ranged between 0.25-0.5, 0.5-0.75, 0.75-1 and DV is ranged between 0.75-1. Whenever the value of Bottleneck indicator is 1, chances of occurrence of Bottleneck is high (Tribelsky and Sacks 2010a). 2.4 INFORMATION EXCHANGE PLATFORMS Even after significant improvements in the design of project documentation software, research highlights that many construction firms still rely on emails to share valuable project related information. This can be trimmed down to the ease in usage of emails over project documentation websites. While hardware access of the team members may also contribute to usage of email for information shared. Capilla et. al. (2012), designed a web-based tool to record and manage architectural design decisions. The decision network developed support system illustrated how key decisions made during the design processes can serve as an inventory for understanding and implementing 17 future similar decisions. By developing a data storage drive and web-based environment facilitates the sharing and reuse processes of architectural knowledge in distributed groups. The key takeaway from the web-based tool as how it identified dependencies and constraints while making a decision. This allocation of dependencies can be used in our study to characterize tasks. Over the years, several approaches have been made to design and improve the project documentation handling. Key software used to address the documentation needs are now cloud based including Procore, Unifier, PlanGrid, JIRA, and several others. Although they incorporate all the administrative needs of a typical construction project, from a research perspective the study of collaboration patterns, and information usage remains in question. The number of advantages of using a cloud based documentation system are countless. There are however some disadvantages mainly concerning the wastage and rework needs of the information. Given the ever expanding and ever improving nature of the industry, the next milestone could be to understand how the information uploaded in the webpages are utilized by the team members. Use of ML and AI concepts can also help in understanding if conclusions can be drawn to improve trends of information sharing. Nitithamyong (2004) studied the most used project documentation data and highlighted ways and directions of improvement. Dave and Koskela (2009) developed a knowledge base platform where all information regarding a construction project was uploaded. Based on the time and project requirements information can be drawn from this knowledge base and used by the teams. However, no explanation was made on how rework and wastage of documents can be made from this approach. 18 Sacks (2014) identified the key factors which contribute to the success of a web-based platform, these included ‘adaptability by the teams, use of advanced technologies on site, contract agreement language between teams, time-constraint of the projects.’ Deviations from these factors could result in a lot of wastage, rework, and may increase information sharing time by involvement of emails and other ways for communication. Table 2.5 highlights what different software used in the industry have in common and also reiterates the need of a new tool for bottleneck identification. 19 TABLE 2.5: REVIEW OF CONSTRUCTION MANAGEMENT WEB-BASED TOOLS CURRENTLY IN USE Software Expertise Area Common Features Document Workflow Project Email KPIs Comments or threaded Meeting minutes Bottlen Management metrics Directory Contact discussion Gantt charts eck identifi cation In Eight Project ☑ ☑ ☑ Management Service Lean KPIs ☑ ☑ ☑ Titan RedTeam Construction ☑ ☑ ☑ ☑ Management FonnCon Document ☑ ☑ ☑ struction Management PlanGrid Project ☑ ☑ ☑ ☑ Management BIM360 Project ☑ ☑ ☑ ☑ Management SAM Issue Management ☑ ☑ ☑ ProDBX RFI Management ☑ ☑ ☑ ☑ Aidi Change ☑ ☑ ☑ ☑ ☑ ☑ Management ISETIA Progress ☑ ☑ ☑ Management KAHUA Efficiency Metrics ☑ ☑ ☑ ☑ Job Lean KPIs ☑ ☑ ☑ ☑ Progress Unifier Project ☑ ☑ ☑ ☑ ☑ Management Through this section the researcher highlighted the key research areas in bottleneck identification through a comprehensive review of literature. This section helps in understanding the specific needs of the web-based tool, improvements which can be to the existing tools to get a more usable and adaptable technique for identifying information bottlenecks. The study aims to incorporate valuable findings of prior literature works and develop new metrics, integrate key qualitative factors with the quantitative ones and produce an ideal model for bottleneck prediction. 2.5 ISSUE TYPES TO INFORM BOTTLENECK CALCULATIONS Construction issues discussed in project team meetings differ in their complexities. Project teams tend to collaborate and work depending on the complexity of the issue in hand (Michelle et. al. 2019). Bell and Kozlowski (2019) highlighted issues during the length of the project can be characterized under Pooled, Sequential, Reciprocal, and Intensive based on the collaboration patterns of the teams. The issues discussed in meeting minutes were changed into different types based on collaboration requirements as described by Bell and Kozlowski (2019). This was done to understand if different types of issues have any impact on bottlenecks. An issue which requires collaboration and engagements from team members from various disciplines could possibly have an impact on occurrence of bottlenecks. This section thus defines the different interdependencies based on Bell and Kozlowski (2019). i. Pooled: Pooled issues are least interdependent where work and activities is distributed separately by members of the team. This type of interdependency is common for low complexity tasks and require minimal collaborations. 21 ii. Sequential: In sequential issues work and tasks flow unidirectionally between team members based on their expertise. Usually, collaboration is not required as information follows its defined path based on the functionality of the team members. Sequential type issues are also common for low complexity tasks. iii. Reciprocal: Reciprocal issues are those which involves back and forth of information between team members till the issue is resolved. Usually, team members of two different expertise coordinate closely to resolve such issues and thus it involves large amount of information and communication. Such issues are common for high complexity tasks which requires rechecks, and reworks. iv. Intensive: Intensive issues are usually of highest complexity. Due to their complexity, there is often no regular pattern which is followed by team members. Such issues are goal oriented, and the project teams of various expertise collaborate for their resolution. Intensive issues are usually high complexity tasks. This section defines four different types of issues. Issues are characterized into their respective type by the researcher based on the protocol after the Gantt chart of issue resolution is developed by using meeting minutes. The issue types are also useful in bottlenecks and the details of that will be addressed in the methodology section of the thesis. The next section highlights the artificial intelligence and its use in bottleneck detection. 2.6 MACHINE LEARNING AND AUTOMATION IN BOTTLENECK DETECTION Through this section the researcher discusses the details of the prior literature works which links machine learning concepts with bottleneck detections and automation in AEC projects. Over the 22 years, many literature efforts have focused on incorporating machine learning into tackling some major issues in the AEC industry. Ahmed et. al. (2016) developed a machine learning model to study develop machine learning models in order to facilitate accurate project delay risk analysis and prediction using objective data sources. Relevant delay risk sources and factors were identified, and a multivariate data set of previous projects’ time performance and delay-inducing risk sources was compiled. Subsequently, the complexity and interdependence of the system was uncovered through an exploratory data analysis. Accordingly, two suitable machine learning models, utilizing decision tree and naïve Bayesian classification algorithms, were identified, and trained using the data set for predicting project delay extents. Although this approach was one of first of its kind to study how machine learning could be used to study delays in projects, the specific constraints, properties of the unique dataset make it difficult for its practical implementation. Vijaya et. al (2010), used a methodology to apply decision tree to analyze the construction labor productivity. The methodology addressed three areas in decision tree construction process. These included selecting more influential attributes, combining multiple attributes, and defining the threshold to ignore irrelevant attributes. This was a great approach to identify key areas where ML algorithms can be implemented in the studies of project documentation and archival data providing more realistic usage. The exact area of implementation however, through this methodology remained unanswered. Capilla et. al. (2012) designed a web-based tool to record and manage architectural design decisions. The decision network developed support system illustrated how key decisions made during the design processes can serve as an inventory for understanding and implementing future similar decisions. By developing a data storage drive and 23 web-based environment facilitates the sharing and reuse processes of architectural knowledge in distributed groups. The key takeaway from the web-based tool as how it identified dependencies and constraints while making a decision. This allocation of dependencies can be used in our study to characterize tasks. 2.7 USABILITY INSPECTION OF WEB-TOOLS Nielsen (1994) highlights a technique called ‘Usability Inspection’ which can be used to understand the usability problems in user interfaces. Nielsen (1994) describes four basic ways to evaluate user interfaces: automatically, empirically, formally, and informally. For this study, empirical evaluation of user-interfaces will be adopted. The web-based model will be tested for its usability and adaptability on two construction industry experts, to determine how the model can provide a more applicable methodology to identify information bottlenecks. Empirical evaluation for user interfaces can be defined as testing the usability of interfaces on real users. Since this project focuses on identifying project bottlenecks on construction projects the empirical testing will be used with construction professionals. Research has highlighted some of basic problems and issues which the developer tends to miss can possibly with identified using the empirical method. On the other hand, using a combination of more than one method of evaluation can often yield best results (Desurvire 1994) (Desurvire et. al. 1992) (Fagan 1986). The detailed components of the breakdown of the inspection methods are discussed below: 1. Heuristic Evaluation: most informal method which involves usability judges to analyze the interface based on standard usability principles (Neilsen 1994). 24 2. Cognitive Walkthroughs: uses a detailed procedure to simulate the user’s problem- solving techniques identifying if the user’s primary goal can lead to the next corrective action in the code (Mack et. al 1994). 3. Formal Usability Inspections uses strictly defined six step rule to use combine heuristic and simplified testing (Kahn and Prail 1994). 4. Pluralistic Walkthroughs: Combines back and forth between users, coders, and human factors in form of meetings (Bias 1994). 5. Feature Inspection: sequence of features used to accomplish typical tasks, checks for long sequences, cumbersome steps, steps that would not be natural for users to try, and steps that require extensive knowledge/ experience in order to assess a proposed feature set (Bell 1992). 6. Consistency Inspection: takes inputs from other designers on how to improve the interface (Wixon et. al. 1994). 7. Standards Inspection has an expert on interface inspection for compliance (Wixon et. al. 1994). For this project, the researcher has adopted formal usability inspection technique and heuristic evaluation to understand the adaptability of the application in construction teams. The standard questionnaire developed for the survey to understand the usability from a construction professional is discussed in the following section: (Mcglin et. al. 2017, Parsazadeh et. al. 2018, Bowman et. al. 2002, Conte et. al. 2009). 25 TABLE 2.7. 1: LITERATURE REVIEW ON USABILITY SURVEY Reference Use in Literature Derivation from Literature Survey Question Framed Mcglin et al. The Buildvis tool will be Formatting of the Did you feel the content used in the 2017 tested on the student teams software/tool is important web-based tool is arranged in the and their feedback on the based on the literature, so right format? formatting will be used to the question focuses on improve the user interface. taking feedback on the formatting. Bowman et al. Discusses distinctive Arranging the content in On a scale of 1-10 how do you rate 2002 characteristics of Virtual appropriate order is focused the clarity of the content? environment and transitional on Bowman et al. (2002), Do you think this information is interfaces. Also, highlights the question framed hence accurate /representative of your most issues found by the takes feedback on clarity of experience with the project? users were related to the the content. clarity of the Virtual Environment. Conte et al. Suggests an important part of Key part on adaptation is Do you think this information is 2009 the usability for a new how feasible it is to use the accurate /representative of your identification technique is information used. This experience with the project? expertise’s input on question discusses whether adaptation. Under structural the data used in readily part of the web-applications, available in different AEC discussions on background projects. information required are shared with the industry specialists. Conte et al. Discusses 10 set rule for Since all projects are In the projects you have worked on 2009 adoption of new platform. different in scope, this so far, is this technique of Two of which are: “Flexibility question highlights whether identification of information and efficiency of use in your the technique used is bottlenecks looks applicable? If so, project”, “ Matching between generalizable and applicable who do you think is suitable to use System and Real-world in AEC projects. this identification technique? implementation?” Parsazadeh et While introducing new This question aims to take • On a scale of 1-10 what is al. 2018 software or applications feedback on whether the your understanding of about a specified topic information provided has information exchange always useful to ask for pre, improved the user’s trends in project teams and post presentation survey. understanding of the topic. after the presentation? • On a scale of 1-10, how do you rate the overall experience? • If you had this tool, do you think this would’ve been useful in identifying the information bottlenecks? 26 2.8 SUMMARY Through this section the researcher discussed the prior literature efforts in the field of bottlenecks in AEC projects. Recent research has focused on defining new metrics inspired from the deep learning concepts ion software development to understand the occurrence of bottleneck. Although, there has been a great development in the field of bottleneck identification in AEC projects over the last two decades, there remains a lack of recent literature in this area. With the advancements in the field of Lean Construction and machine learning, new techniques can be developed to identify and modify the current methodologies of bottleneck identification. In the following section, the main methodologies for achieving the goals of the research are discussed. 27 CHAPTER 3 METRICS REVISITED With section 2.1.3 the researcher presented the key metrics that were reviewed through literature and also discussed the potential pros and cons of each of them. Through this chapter the researcher discusses the two new metrics which were developed through this research, Productivity and Average Resolution Speed. The researcher then discusses the modifications made to the existing metrics of Development Velocity (DV), Work in Progress (WIP) and defines discusses their potential in the web-based tool. 3.1 MODIFIED BOTTLENECK METRICS DV and WIP metrics were modified because the information package definition requires complex calculations and estimating the package size of the information uploaded or shared. Sacks and Tribelsky (2010) discussed the information attributes of each type of item used during an AEC project. These attributes are then counted individually for the whole project and that comprises an information package. Since this calculation is difficult to achieve, DV and WIP definitions were modified as discussed below. Frequency of information publication and all project issues discussed during bi-weekly project meetings were used to calculate DV and WIP respectively. WIP for modified from a team effort, through the works of IOPT4 research team (iopt4.msu.edu). WIP modifications is discussed in greater detail through a team research paper which is currently under review. DV was modified by the researcher and the modified metrics were presented to the group for review and feedback. The modified definitions are discussed 28 below, and Table 6 highlights the major differences between the metrics used in the literature and the modified version. • Development Velocity (Modified): Development velocity is calculated as the development in available information for team members between two-time intervals. IP represents information package which is the total information published at a particular date. DV a-b = (IP b – IP a)/ (D b- a) DV a-b – Development of information between a and b IP a– Total information bits available at time a IP b- Total information bits available at time b D a-b – difference of days between time a and time b. • Modified equation of WIP for the research: WIP is defined as the resolution rate of the issues using project documentation data. (Adapted from the works of IOPT4 team - https://iopt4.msu.edu) WIP = (IS a – IS b) x (IP ab) IS a – Issues resolved using project data at time a IS b – Issues resolved using project data at time b IP ab – Total information bits between time a and b 29 TABLE 3.1: KEY DIFFERENCES BETWEEN ORIGINAL AND MODIFIED METRICS Metrics Used in Literature Modified Metrics Development Definition from Literature: Modified Definition: Velocity (DV) Development velocity (DV) can be Development velocity (DV) is defined as the development of calculated as the development in information as represented by the available information for team accumulation of details (Tribelsky members between two-time and Sacks 2010) intervals. The first time interval is when project information is made available to project teams from the web-tool (Garcia et. al. 2020) Uses package size which is Uses cumulative information bits. calculated by accumulating all Adds all bits of information information attributes. published at a particular date to replace package size. Uses a software called Autovue to Manually imports uploads from track and calculate Package size. project documentation websites to calculate information bits and filters emails with attachments and overall size more than 75KB were filtered to track information shared via email (Mulugeta 2010). Formula used: Modified Formula : DVt = (PSt - PSt1) / (Tt -Tt1) DV a-b = (IP b – IP a)/ (D b- a) DVt – DV at time T DVa-b – Development of information PS – Package size at time t and t1 between a and b T – Time interval at t and t1 IPa– Total information bits available at time a IPb- Total information bits available at time b D a-b – difference of days between time a and time b. 30 TABLE 3.1 (cont’d) Work in Definition from Literature: Modified Definition: Progress (WIP) The number of available but unused WIP is defined as the resolution rate information packages. of the issues using project documentation data. Uses package size which is Uses number of unresolved issues calculated by accumulating all and cumulative information bits information attributes. between two dates Uses a software called Autovue to Meeting minutes issues are tracked track and calculate Package size. manually through excel document and by preparing a Gantt chart schedule, project documentation data is imported, and emails are filtered. Formula used: Modified used: WIP = ∑ nIPj j=1 (t- Tupj) PSjUj WIP = (IS a – IS b) x (IP ab) WIP – Work in Progress ISa – Issues resolved using project data PSjUj- Uj=1 if package j has been viewed at time a or downloaded by a team member ISb – Issues resolved using project data Tupj – The day at which the package was at time b uploaded. IPab – Total information bits between time a and b 3.2 PRODUCTIVITY AND ISSUE RESOLUTION SPEED Two new project performance metrics were adopted by the researcher to understand and study the team performance and give insights into studying the bottlenecks during project delivery. Construction Productivity is defined in terms of input and output of volume of work performed against the fixed goal. On similar grounds, Productivity in this context is defined as the efficiency of project teams in resolving issues in hand. Whereas average days to resolve is 31 the average resolution speed in days of the teams in resolving these issues. The calculation formula for both these metrics is discussed below. • Productivity – Productivity is defined as the percentage efficiency of project team members in resolving ongoing issues discussed in project meetings. The productivity definition is adapted from Staron and Medding (2011) and is discussed below: Productivity = (nRIS b – nRIS a)/ (IS a - b) *100 nRIS a – Number of resolved issues by time a nRIS b – Number of resolved issues by time b IS a-b – total number of issues to be resolved between time a and b. • Average Days to Resolve Issues (AR) – AR is the average days project team members take to resolve an issue measured between a time interval. AR = ∑a b (dIS) / IS dIS – Total number of days required to resolve n Issues between a and b. IS – total issues between a and b. 3.3 BOTTLENECK METRICS AND ACTIVITY TYPES This section discusses the four different issue types Pooled, Sequential, Reciprocal, and Intensive and their implications on bottlenecks prediction. Through section 2.5, the researcher introduced the definitions of the four issue types, this section studies their implication on 32 bottleneck identification. The results of the issue types are also verified from a parallel research effort by IOPT4 team (iopt4.msu.edu) and the research paper produced from the team effort is currently under review. 3.4 SUMMARY Through this section, the researcher addresses the section 1 of the research goal: Developing quantification metrics and modifying information metrics formulas to quantify team performance and project performance. Two new team performance metrics were developed using lean construction definitions and introduced in section 3.2. Through literature review of the metrics as previously discussed in section 2.1.3, DV and WIP metrics were modified by changing the definition of package size. The researcher also presented the differences between the new and modified metrics through table 6. The next section discusses in detail the section 2, section 3, and section 4 of the research. 33 CHAPTER 4 METHODOLOGY 4.1 INTRODUCTION The previous chapter establishes the research gaps and need of a new study in identification of bottlenecks. To answer to the research question, a new web-based tool was developed by developing new metrics (Productivity, Average Resolution Speed), and metrics developed by (Tribelsky and Sacks 2010a) were modified to identify project bottlenecks. The web-tool was then presented to industry experts via an interview and their feedbacks were used to improve the tool. The final improved tool is presented for the readers. Through this chapter the researcher discusses the research approach taken to achieve the objectives of the research. A summary of research objectives is presented, followed by detailed breakdown of the steps. The research approach includes a combination of background calculations, development of quantification metrics, coding to develop the web-based tool, and expert interviews. 4.2 RESEARCH GOALS AND OBJECTIVES Research Objectives and the methods followed to achieve those objectives are summarized through the table 4.2: TABLE 4.2: RESEARCH OBJECTIVES AND METHODS Research Objectives Methods 1. Develop new metrics and modify Review of Literature and Lean Construction existing KPIs. Productivity, Average concepts to develop team performance Resolution Speed have been metrics termed as Productivity, and Average developed through this research, Resolution Speed. Quantifications provided by Tribelsky and Sacks (2007) for DV, and 34 TABLE 4.2 (CONT’D) while the definitions of DV and WIP WIP modified based on the dataset available modified from the literature. and to improve usability. 2. Adopt activity types based on the Tasks discussed during bi-weekly project literature (Bell and Kozlowski 2019) meetings for the two-projects studied for (i.e., Pooled, Sequential, Reciprocal, this thesis were segregated based on their and Intensive) based on their start date, end date, and parties involved. collaboration requirements, explore These activities were then separated into their impacts on bottlenecks to one of the four types Pooled, Sequential, further improve bottleneck Reciprocal, or Intensive based on the predictions during project delivery. collaboration requirement and complexity of the tasks. 3. Develop a web-based tool to import A web-based tool is developed using Python project documentation data and coding by creating a dashboard which inputs report on bottlenecks. Microsoft excel sheet with project documentation data such as Information on Meetings, Information Exchange between project teams to identify and report on bottlenecks during the length of the project. 4. Modify the web-based tool based on Expert interviews were organized, and the expert feedback and provide future feedback received was implemented in the recommendations. python code. The results are discussed and future direction of work to improve the web- based tool even further are discussed. The section 4.3 introduces the research approach followed to achieve the research goal. 4.3 RESEARCH APPROACH AND SCOPE This research is focuses on development of a bottleneck reporting tool and tests the adaptability and usability of the tool in AEC teams. The bottleneck calculation is performed between intervals. Intervals are decided based on the progress loops of the project (Garcia et. al. 2020). The data points of the project were analyzed and broken down into monthly time intervals for each of the following phases Schematic Design (SD), Design Development (DD), 35 Construction Document (CD), and Construction for both projects. The bottlenecks during these datasets are then reported using the web-based tool. Usability interviews is conducted by the researcher and based on the feedbacks received by the expert interviews, the researcher discusses the possible future implications of the tool and whether this tool can be successfully implemented and used during AEC projects of different scopes. Therefore, the research follows a combination of mixed methods. Literature review was used to identify the key questions which are to be asked during the expert interviews. The data collection for the study was collected by the research team over a period of 2 years and included archival data from two high visibility projects in mid-west USA. Finally, quantitative analysis was used to develop metrics and process the collected data. 4.4 RESEARCH METHODOLOGY To address the need in the literature, the goal of this research is to study the adaptability and feasibility of the bottleneck reporting tool in AEC Projects. The study was also divided into four sections each of which use different methods. • Section 1: Developing quantification metrics and modifying information metrics formulas to quantify team performance and project performance. • Section 2: Automating the metrics and using the project documentation raw data. Additionally, automating the different types of issues discussed between project teams. • Section 3: Developing a web-based used using python coding and reporting on bottlenecks. 36 • Section 4: Interviewing industry experts to get their feedback on the adaptability and usability of the tool. Figure 4.4 presents the flow-chart which presents the methodology used by the researcher. 37 Identification of Problem Literature Review Preparation of Expert Review of Existing Interview Questions Metrics Review of Existing Web-based Tools Identification of Gap in Literature Data Collection Email Exchange Data Project Documentation Data Meeting Minutes Data Data Analysis and Processing Developing Excel for Modifying the Metrics Model Input FIGURE 4.4: RESEARCH METHODOLOGY 38 FIGURE 4.4 (cont’d) Development of the web-based tool Expert Interviews Modified Web-based Conclusion, and Tool Recommendations There has been limited research on development of a web-based tool to identify and report on bottlenecks for AEC Projects. This research draws inspiration from prior research work in identification of bottlenecks in AEC teams and uses Automation in Python to semi-automate the raw project documentation data to report on suspected bottlenecks. The validity, usability, and adaptability of this tool is discussed via expert interviews and their feedback is presented in the results section, along with possible directions to make this tool even more feasible. The literature review for the study can be divided into three main sections for different portions of this study: 1 Identification of metrics and methodologies used by prior researchers to identify bottlenecks in AEC projects. 2 Identification of the existing web-based platforms and study their advantages and disadvantages. 39 3 Literature review to help frame the type of questions to be asked to industry specialists in the expert interviews. The data collection was performed by the research team over a period of two years as we collected the archival data of the two high visibility projects. The type of data used for this study include email exchange data from email interactions between project teams, project documentation data which was made available to us through online web-based platforms the two projects used, bi-weekly project meeting data provided to us in form of PDFs by the project managers of the two projects. These data sets were processed and converted into usable formats which are then used for analysis and coding. The researcher then developed a Python code in Visual Studio which extracted raw data directly from the MS Excel sheets and created a dashboard to display and report on the bottlenecks, the tool also provides recommendations on how to avoid these bottlenecks while detailing the various Project Performance and Team Performance metrics. Finally, to test the usability of the tool, expert interviews were conducted. The recorded feedback received through these interviews were used to improve the model and provide future recommendations for the study. 4.5 DATA COLLECTION AND PROCESSING The data for this research were collected from two mid-size projects located in Midwest, USA. One of the projects is an Expansion project while the other is a major renovation project. The data were largely archival in nature comprising of email exchange, meeting minutes, ethnographic and project documentation data. 40 Since this thesis is a part of a larger effort by the I-OPT4 Research Team (https://iopt4.msu.edu/), protocols were developed for extracting and processing each set of raw data. Email data was extracted through a macro which was used in the project managers system. The research team was provided access as guests to the documentation platform of Unifier and PlanGrid. From that relevant data was extracted and formatted in Microsoft excel. Meeting minutes were provided to us after every weekly project meeting by the project managers of the respective projects. The following figure highlights the different sets of raw data and their formatted output. Each of the sections 4.5.1, 4.5.2, and 4.5.3 are divided into two subsections which discusses the data collection and analysis part and web tool python code in detail. Table 4.5 highlights how each data type is used and processed for the study. TABLE 4.5: ARCHIVAL DATA TYPE, AND DATA PROCESSING Archival Data Type Data Processing Use in the Tool Email Exchange Data Emails cleaned and emails with Tool filters and graphically attachments are cleaned. represent how many emails each project party (Owner, Designer, or GC) receives. Project Documentation PlanGrid: PlanGrid is online project Project Documentation data Data data management website. Both imported through PlanGrid the projects used PlanGrid and was cumulated along with updated it regularly. Each dataset Unifier and how much updated on PlanGrid was imported information each team has to on excel sheets which highlighted process was calculated using the timestamps, the type of data the tool. This information is updated, and the responsible party then used to calculate the for resolution. quantification metrics Unifier: Unifier is similar to PlanGrid including DV, WIP. and was used during the course of the project. The researcher followed similar approach for Unifier and Imported project documentation data in Excel sheet. Meeting Minutes Meeting minute PDFs were Issues discussed in meeting converted to MS Excel format so minutes are very crucial to that the tool can use the issues determining the bottleneck 41 TABLE 4.5 (cont’d) discussed in the minutes. The and for calculation of project meeting minutes were formatted performance and team based on the name of issue, start performance metrics. date, resolution date, and responsible parties. Section 4.5.1 Discusses each type of archival data in detail. 4.5.1 EMAIL EXCHANGE DATA 4.5.1.1 DATA COLLECTION AND ANALYSIS The email exchange data was available in three different formats based on the sources. Designer, Owner, and GC’s email exchange information was available in different formats. A Visual Basic for Applications (VBA) code (Appendix E) was developed to extract the email information from Microsoft Outlook for the GC emails. The other two types of emails were shared by the project personnel with the researcher. The raw email data was used to extract emails with attachments. Email exchange remains a popular form of information exchange between project teams (Sacks and Tribelsky 2007, Mulugeta 2010). The email exchange data was cleaned to represent Timestamps of email exchange, receiver information, sender information, number of attachments. This information was used as an input for the web-based tool. Figure 5 represents the raw email data before cleaning. Figure 6 represents cleaned email data which is imported by the web-based tool. 42 FIGURE 4.5.1: SAMPLE RAW UNCLEANED EMAIL FILE TABLE 4.5.1: SAMPLE CLEANED FILE TO STUDY THE NUMBER OF INFORMATION IN FORM OF ATTACHMENTS SHARED BETWEEN TEAMS. Sender Role Project Party Date and Time No. of Attachments Designer Owner Date and Time 1 1 Owner Designer Date and Time 2 2 GC GC Date and Time 3 1 Owner Owner Date and Time 4 3 GC Designer Date and Time 5 4 Designer GC Date and Time 6 2 Owner Designer Date and Time 7 3 GC Owner Date and Time 8 5 Owner GC Date and Time 9 2 GC GC Date and Time 2 10 4.5.1.2 WEB-TOOL DEVELOPMENT As discussed in detail with table 6, section 4.5.1.1, the formatted email dataset file is use as the input in the model’s code. These values are all stored in a temporary database which is created through the code. The code then develops a blank dashboard server which then uses plotly library to display the email exchange data as it is received by owner, designer, and GC. The time 43 stamps are filtered in accordance with the bi-weekly project meeting dates. The following code figure 4.5.1.2 highlights the code in detail. # ----------------------- df100['upcoming_meeting_date'] = df100['Meeting Date'].shift(periods=-1) df100['days_between_meeting']=df100['upcoming_meeting_date']- df100['Meeting Date'] df100['firstcount']=(df100['Emails to D']+df100['Email to O']+df100['Email to GC']+df100['PlanGrid']+df100['Unifier']) df100['secondcount']=df100['firstcount'].shift(periods=1) df100['days_between_meeting']=df100['days_between_meeting'].astype('str') def func1(x): x=x[:2] return x FIGURE 4.5.1.2: FUNCTIONS DEVELOPED TO IMPORT THE EMAIL EXCHANGE DATA IN THE CODE. The code develops function which import and filters the emails based on whether they are received by GC, Owner, or Designer. The code then links the dates of the emails with the bi- weekly meetings and stores in a temporary database. The results of the code and graphical representations are discussed in section 6.6.2. 4.5.2 PROJECT DOCUMENTATION DATA 4.5.2.1 DATA COLLECTION AND ANALYSIS Project Documentation data is often the result of planning process of construction and is pivotal for project management (Kozlovska et. al. 2016). The project documentation software used for the two mid-sized projects were PlanGrid and Unifier. The researcher was granted access to these software and imported the data sets into Microsoft excel to study the 44 information flow. The raw imported files were then cleaned to highlight the timestamps of information publication, number of pieces of information shared, responsible party for information exchange. The cleaned excel is then used as in input for the web-based tool. Project documentation data is used to study the information exchange patterns, calculate DV, and WIP. The project documentation websites used for this research had multiple information uploading options, from the pre-construction phase to the construction execution phase. The websites are designed to cater the needs of the different phases of the projects and have file uploading options including bidding documents, contract documents, budget allocation documents, change orders, RFIs etc. The table 4.5.2 highlights the different types of documents and information used for calculation of information bits which helps in calculation of WIP and DV. TABLE 4.5.2: TYPE OF INFORMATION SHARED IN UNIFIER AND PLANGRID. Type of Document in Project Documentation Use in Project websites Project Approvals Documents related to official approvals or site permits. Contract Documents Has documents related to agreed contracts between different subs Project Specific POs Special project requirements PDFs Design Services POs Special design requirements and Architects reviewed Docs Bidding Documents Official bidding record of the project Budget Adjustments All adjusted budgets throughout the length of the project are stored here Budget Allocation Potential budget allocations for future work Construction Issues Active issues on site Construction Waste Management Documents related to how waste will be managed on site Contracting Contract related issues or legal issues 45 TABLE 4.5.2 (cont’d) Misc Costs Additional costs during execution which could be billed Insurance All the insurance required for the project Owner Services Documents related to the services and terms provided by the owner Plan Reviews Change in drawings or plans Potential Costs Potential costs helps in requesting bills RFIs Request for information Submittals All submittals Transmittals All transmittals Schedule of Values All schedule of values Construction Change Directory All Change orders Unpublished Documents Unpublished documents, miscellaneous documents or archival documents which can be reviewed in case of need Drafts Documents which are currently been updated or require revision. Whereas FIGURE highlights the cleaned documentation format in Microsoft excel which is used for the web-based tool. 46 PlanGrid Unifier FIGURE 4.5.2: CLEANED PROJECT DOCUMENTATION DATA Figure 4.5.2 highlights the cleaned data points which are recorded at the dates of the actual bi- weekly meetings which occurred throughout the length of the project. The types of information tracked on bi-weekly project meetings are explained in detail with figure 8. For example, between January 1st, 2019 to the next meeting date at February 11th, 2019: 0 information was uploaded in software 1 (PlanGrid), and 19 information bits were uploaded in software 2(Unifier). This way, all pieces of information uploaded by the admin are tracked and recorded consistently. 47 4.5.2.2 WEB TOOL DEVELOPMENT As discussed in detail with figure 4.5, section 4.5.2.1, the formatted project documentation file is used as the input in the model’s code. These values are all stored in a temporary database which is created through the code. The code then develops a blank dashboard server which then uses plotly library to display the project documentation data of the website 1 (PlanGrid) and website 2 (Unifier) separated based on the bi-weekly project meeting dates. This separation helped the researcher correlate how much information is being shared within project teams between two consecutive meeting dates. Figure 4.5.2.2 highlights the code developed for extracting the data from excel sheet and storing it in database, the results are then discussed in detail in section 6.6.2. df100 = df1 # ----------------------- df100['upcoming_meeting_date'] = df100['Meeting Date'].shift(periods=-1) df100['days_between_meeting']=df100['upcoming_meeting_date']- df100['Meeting Date'] df100['firstcount']=(df100['Emails to D']+df100['Email to O']+df100['Email to GC' ]+df100['PlanGrid']+df100['Unifier']) df100['secondcount']=df100['firstcount'].shift(periods=1) df100['days_between_meeting']=df100['days_between_meeting'].astype('str') def func1(x): x=x[:2] return x FIGURE 4.5.2.2: DETAILS OF THE CODE USED FOR INFORMATION EXTRACTION FROM DOCUMENTATION WEBSITE 48 4.5.3 MEETING MINUTES DATA 4.5.3.1 DATA COLLECTION AND ANALYSIS Meeting minutes represent the main discussion points of the bi-weekly project meetings in AEC projects. The meeting minutes for the two projects used in this research was provided in the form of PDF documents. Each of the points discussed in the meetings represent an ongoing issue with the project. Each of these issues were tracked over successive meetings to understand how long a particular issue lasts, who is responsible for the resolution of the issue, what were the main discussion related to the issue. Based on this, the meeting minute available for the two projects were converted to an excel document as represented in figure 4.5.3. Item code is unique code given to each of the issues in the meeting minutes. Description discusses the brief explanation of the ongoing issue. Start and end dates are used to understand how long a particular issue is discussed in the meetings. Days to complete is the difference between the start date of the issue to the end date of the issue. Finally, Responsible party represents which one of Owner, Designer, or GC was responsible for resolving the issue. FIGURE 4.5.3: FORMATTED MEETING MINUTES DOCUMENT 49 The figure 4.6 was imported in the web-based tool and was semi-automated to calculate the productivity, average resolution speed, and work in progress. 4.5.4 PROGRESS LOOPS AND INTERVALS One of the main contributions of this thesis to the literature is the development of progress loops or intervals between different phases of design, planning, and construction. The researcher used archive datasets to figure out how the project progressed (Garcia et al. 2014; Marks et al. 2001). During the design phase, SD, DD, and CD episodes were further divided into monthly time periods based on project progress (i.e., analyses showed cost growth and scope revisions as the key metrics to determine progress loops during the design phase). The whole design phase was divided into seven intervals, each lasting around one month (i.e., SD consisted of 3 intervals, DD consisted of 2 intervals, CD consisted of 5 intervals, and construction consisted of 11 intervals). The CD and the commencement of the building phase were separated by three days. Productivity calculations, which were employed as a measure of sustainability results, were also helped by archival datasets. The breakdown of phases into smaller intervals allowed the researcher to understand information trends and growth at a micro level which helped in accurate identification of bottlenecks. The web-based tool was also programmed to provide outputs based on these intervals. Project teams working on new product development projects go through episodes (Marks et al., 2001), which are temporal cycles made up of a collection of coordinated actions that contribute, directly or indirectly, to the entire project's progress toward its end goals (Weingart, 1997; Zaheer et al., 1999). Episodes can be characterized as definable periods of time during 50 which progress accumulates and is evaluated at the end when feedback is provided (Mathieu & Button, 1992). After analyzing project outcomes, project team members can determine where the project stands and begin a new cycle, resulting in a series of episodes that are correctly connected (Marks et al., 2001). For example, an AEC project team that progresses in mechanical design over an episode may receive feedback on outcomes estimates at the conclusion of the episode suggesting that the project is overbudget and will be completed beyond the deadline. The project team members would then have an accurate picture of the project's present situation and would take appropriate action in the following episode. Marks et al. (2001) distinguished between two sorts of episodes: action phases, in which project team members do activities aimed at directly enhancing project progress, and transition phases, in which prior performance is evaluated and planned choices are made. Projects move through a series of transition-action stages, with the output of each serving as the input for the next (Marks et al., 2001). While team members work on AEC projects, progress loops are created between the time a choice is taken and the time feedback on project results is received, allowing the quality of previous decisions and progress to be assessed. Progress loops are a cycle of transition- action-transition phases in which, first, planning decisions are made; second, project team members perform tasks in accordance with the decisions made in the first stage, resulting in increased project progress; and third, feedback, or, in other words, project outcomes estimates updates are obtained, allowing the evaluation of both project progress and the adequacy of decisions made in the first stage. Following that, AEC project teams enter a new progress loop. The term "progress" in this article refers to the proportion of a project that has been completed. Progress loops do not relate to quantitative progress (it is anticipated that progress 51 will rise, but the amount is unknown), but rather to qualitative progress, or the positive or negative influence of progress on project results. Positive progress loops increase project results compared to the previous estimate, whereas negative progress loops harm them. Neutral progress loops are produced when project outputs remain constant. Progress loops may certainly enhance certain results while wreaking havoc on others. In this instance, priorities between outcomes can be set or a system that assigns weights to each result can be constructed to determine if a progress loop is positive or negative; however, this study does not go any further on this topic. Furthermore, the length between the point when planning choices are taken and the point where feedback is acquired might vary, therefore progress loops can have variable temporal lengths. The progress loops were identified based on the following protocol developed by the researcher: 1. The meeting minutes, and three week lookahead schedule published by the project teams were studied and analyzed to identify any major milestones coming up which had potential impact of cost or schedule. Such activities or issues marked a potentially important day, which was selected as the end period of the interval. Through analysis of the meeting minutes and three-week schedule, it is identified that each interval within a phase has a duration of around 30-35 days. 2. Once the intervals and the key activities were fixated it was submitted for a review to another researcher in the team with expertise in experience in detecting progress loops) for review. After the review and acceptance of the steps followed for the first phase (SD) 52 intervals, the researcher followed the same steps to finish development of intervals in each phase. 4.5.5 WEB-BASED TOOL Meeting minutes data is an important source of information to track all the active issues ongoing during all phases of the project. The meeting minutes file is developed by the researcher over the period of the duration of the two projects used for the study. The meeting minutes extraction is currently being study to be fully automated to save time and produce faster results. The fully automated code will directly extract data from the meeting minutes PDF files using Artificial Intelligence and will not require conversion to excel sheets However, it is beyond the scope of this thesis. Through the code as displayed by the following figure, the data is extracted and is stored in a temporary database which will then be used to study the different trends and calculate WIP, Productivity, and Average Resolution Speed of the teams in resolving these issues. df100['num_of_days']=df100.apply(lambda x: func1(x['days_between_meeting']), axis =1) df100['num_of_days']=df100['num_of_days'].replace('Na',0) df100['secondcount']=df100['secondcount'].fillna(0) df100['secondcount']=df100['secondcount'].astype('int') df100['num_of_days']=df100['num_of_days'].astype('int') df100['dv']=(df100['firstcount']-df100['secondcount'])/df100['num_of_days'] df100['dv']=df100['dv'].replace(df100['dv'][0],0) df100['sum_of_issues']=(df100['Issues to O']+df100['Issues to GC']+df100['Issues to D']) df100['sum_of_issues']=df100['sum_of_issues'].fillna(0) df100['sum_of_issues']=df100['sum_of_issues'].astype('int') df100['sum_of_issues_second_meet']=df100['sum_of_issues'].shift(periods=1) df100['WIP']=(df100['sum_of_issues']-df100['sum_of_issues_second_meet']) df100['WIP']=df100['WIP'].fillna(0) df100['Month']=df100['Meeting Date'].dt.month FIGURE 4.5.4: CODE TO EXTRACT MEETING MINUTES ISSUES FROM THE EXCEL DOCUMENT. 53 FIGURE 4.5.4(cont’d) df100['Month'] = df100['Month'].replace({1:'January',2:'February',3:'March',4:'Ap ril',5:'May',6:'June',7:'July',8:'August',9:'September',10:'October',11:'November ',12:'December'}) df1001=df100[['Meeting Date','upcoming_meeting_date','dv','WIP','Month','Phases', 'Comments']] df1002 =pd.melt(df1001, id_vars=['Meeting Date', 'upcoming_meeting_date','Month'] , var_name=[('dv', 'WIP')], value_name='Value') df1002.columns=['Meeting Date', 'upcoming_meeting_date', 'Month', 'category','Val ue'] Through this section the researcher discusses the details of the python code developed to implement the web-based tool. The section is divided into six sub-sections each of which discuss the different tabs in the web-based tools. The web-based tool was coded in Visual Studio by importing the python data libraries which are used to display results in the dashboard created through the code. The libraries imported and their primary functions are explained below in table 4.5.4: TABLE 4.5.4: PYTHON LIBRARIES AND THEIR FUNCTIONS Imported Libraries Functions Dash Used to create dashboards and interfaces for web-tools and applications. NumPy Used to work with numbers as arrays. Statistical functions are implemented in the tool using NumPy. Plotly Plotly is used to develop interactive and high-quality graphical outputs. For the web-based tool, Plotly is used to graphically represent Team performance and project performance metrics. Pandas Pandas is used in this study for analysis, and for bottleneck quantification. The following sections discuss the tool through individual navigation tabs. 4.6 USABILITY INTERVIEW 4.6.1 BOTTLENECK REPORTING TAB The web-tool is divided into 2 separate sections, Bottleneck Reporting tab, which reports on bottlenecks identified during the length of the project by using the calculation and 54 quantification defined by the researcher. The bottlenecks are reported using DV and WIP metrics modified from the definitions provided by Tribelsky and Sacks (2007). DV and WIP formula as discussed in detail in section 4.1 is coded in python. Using project information exchange which was in form of meeting minutes, email exchange of information and information provided through online project documentation software, the code calculates DV and WIP. It then compares the values of these calculations using the metrics adopted from Sacks (2010), finally the dates on which the chance of occurrence is high are reported. Figure 4.6.1 is a snapshot of the reporting page of the web-based tool, whereas figure 4.6.1.2 is code used to quantify DV and WIP. FIGURE 4.6.1: SNAPSHOT OF THE BOTTLENECK REPORTING PAGE def funx(x): x = float(x) if x in(twofive): return '0 - 0.25' if x in(five): return '0.25 - 0.50' if x in(sevenfive): return '0.50 - 0.75' if x in(one): return '0.75 - 1' def funy(y): y=float(y) FIGURE 4.6.1.2: SNAPSHOT OF THE DV AND WIP CONDITIONS TO REPORT ON POSSIBLE BOTTLENECKS. 55 FIGURE 4.6.1.2(cont’d) if y in(twofive): return '0 - 0.25' if y in(five): return '0.25 - 0.50' if y in(sevenfive): return '0.50 - 0.75' if y in(one): return '0.75 - 1' df150['dv_range'] = df150.dv.apply(funx) df150['wip_range'] = df150.WIP.apply(funy) def fun2(x,y): if (x == '0.25 - 0.50')&(y == '0.75 - 1'): return 1 if (x == '0.00 - 0.25')&(y == '0.75 - 1'): return 1 if (x == '0.50 - 0.75')&(y == '0.75 - 1'): return 1 4.6.2 INFORMATION FLOW OF THE PROJECT The information exchange of the project is tracked through five different metrics which are used to study the team performance and project performance of the project. The information metrics measured through the next section of the tool are: • Email Information: Tracks the number of emails received by owner, designer, and general contractor on monthly basis. Figure 4.6.2 highlights email information section in the tool. The email information section is coded in python by cleaning the email exchange data set discussed in section 4.5.1 and adding number of emails received by each party per month. • Web-Based Project Documentation Data: tracks the number of updates or information bits uploaded in PlanGrid and Unifier on a monthly basis as discussed in section 4.6.2. The code for this section is developed by adding information shared by each platform per month. Figure 4.6.2 highlights the project documentation data in the tool. 56 • Issue Report: Issue Report is the characterization of issues discussed in the bi-weekly meetings into four different types Pooled, Sequential, Reciprocal, and Intensive. The purpose of these characterization is because each of these types has different implications on the complexity and collaboration requirements of the issues as discussed in section 2.4. The coding for this performed based on the protocol developed by the researcher, and by studying the number of parties involved in resolving a particular issue discussed in bi-weekly meetings. Figure 4.10 shows the snapshot of the tool with Issue Report. • Average Days to Complete: Average Days To Complete is divided into two types, Average days to resolve per expertise role and average days to resolve for each type of issues as discussed in detail in section 4.1. Figure 4.6.2.2 shows a snapshot of the average days to resolve page in the tool. • Productivity: Productivity as defined under section 4.1 is calculated based on each expertise role throughout the length of the project as shown in snapshot 4.6.2.3. 57 FIGURE 4.6.2: SNAPSHOT OF INFORMATION EXCHANGE PAGE IN THE WEB TOOL FIGURE4.6.2.2: SNAPSHOT OF AVERAGE DAYS TO RESOLVE PAGE IN THE TOOL 58 FIGURE 4.6.2.3: SNAPSHOT OF THE PRODUCTIVITY PAGE IN THE TOOL 4.6.3 BOTTLENECK PREDICTION AND POTENTIAL REMEDIES Bottleneck Prediction/Potential Remedies provides insights to the users on why the bottleneck has occurred and ways to tackle such type of issues for future projects. The snapshot 4.6.3 highlights how this section is presented in the tool. It used the type of bottlenecks reported by the Bottleneck reporting tool to provide recommendations for tackling these issues. The predictions are provided based on the findings of the IOPT Research Team (iopt4.msu.edu). FIGURE 4.6.3: SNAPSHOT OF THE BOTTLENECK PREDICTION/ POTENTIAL REMEDIES 59 A qualitative assessment of the interview findings is performed since, the sample size of interview is small and think-aloud protocol was adapted to record the interview feedbacks. The participants were the Project Managers in charge of the two high profile projects and their feedbacks were recorded and addressed to improve the baseline model. The interviewees were given command of the screen and allowed to navigate through the tool, they provided feedbacks consistently which will be discussed in detail in section 4.3.2. The participants were selected so they are representative of the target audience of the tool which is management team of the AEC Projects. Figure 4.7 as adapted from Budiu (2017) was used to ensure consistency during the development and re-development of the web tool. FIGURE 4.7: DESIGN AND THE RE-DESIGN FEATURES OF THE WEB-TOOL. Through the figure 4.7, the researcher presents the steps in which the qualitative assessments of the tool will be made. The table 4.6, highlights the different sections in thesis where the 4 steps of qualitative assessments are discussed. 60 TABLE 4.6 : QUALITATIVE ASSESSMENTS AND SECTION DESCRIPTIONS Qualitative Assessment Step Section and Description 1. Evaluate initial site Section 4.5 addresses the initial requirements for the webtool, and chapter 3 develops the key metrics which are required for implementing the same. 2. Reformulation and Section 3.1 discusses the reformulation of the Redesign metrics. Section 6.2 discusses the comments received from the interviewees which will help the researcher in redesign. 3. Evaluation of the The redesign is discussed and presented multiple redesign times with the IOPT4 Research Team 4. Comparison between Section 6.3 discusses the initial and final tool. new and initial design 4.7 RESEARCH QUALITY Internal and External validity, inter-coder reliability tests were performed to maintain the quality of the research (Sargent 2013). Internal validity was maintained by using several iterations and conditions in the web-tool while running to ensure consistency. The tool was reviewed by the IOPT4 Research Team (iopt4.msu.edu) several times to ensure external validity. The raw datasets used for the inputs of the tool were coded and extracted using a protocol developed by the team to ensure coding reliability. The interview protocol attached in Appendix A and G went through a detailed Institutional Review Board (IRB) approval to maintain quality and ensure compliance to standards. 4.7.1 ITERATIVE RELIABILITY FOR DETERMINING THE TYPES OF ISSUES The meeting minutes document for both Project 1 and Project 2 used for this study were distributed to two researchers. Researcher 1 and researcher 2 separated issue types of the meeting minutes based on the protocol developed. The two researchers performed issue 61 segregation for the first ten meeting minutes for project 1 and project 2 (Sun 2013). After that, results were compared and found out to be similar. The results were then submitted for a review to the researcher 3 with extensive experience with the topic to conduct a final review. After the review and acceptance of the steps followed for the first ten meeting minutes, Researcher 1 followed similar approach to separate all the issues discussed in meeting minutes for both the projects. The following section presents the protocol used and the steps followed for the development of the protocol for identification of issue types from the meeting minutes issues. 4.7.2 DEVELOPMENT OF PROTOCOL FOR ISSUE TYPES The protocol for the issue types based on workflows was developed based on the works of Bell and Kozlowski (2002), which defined four different types of activity types – pooled, reciprocal, sequential, and intensive. The four types of workflow interdependencies were separated based on how different nodes or teams collaborate and contribute to finish a task and based on the complexity of a particular task. Appendix H discusses the detailed example of how issue types were identified for each activity type. Type of Dependency (From Meeting Minutes) • Pooled- Pooled activities are least interdependent arrangement-work. Activities are performed separately by all team members and then combined into a finished product- within a single organization. (If one organization is involved, it is pooled) 62 • Sequential-work and activities flow unidirectionally from one member to another-one organization to another. (If two organization is involved, going in one direction, it is sequential) • Reciprocal-is characterized by work and activities that flow back and forth between team members, one by one, overtime-between different organizations. (If two organization is involved, going in bidirectional, it is sequential) • Intensive-diagnose, problem solve, and/or collaborate simultaneously as a team to accomplish their task. (If more than two organization is involved, going in bidirectional, it is intensive). The two researchers followed the above protocol for both the projects, results were then compared and presented to the Researcher 3. After evaluation of both the results, the researcher 1 completed the coding for the rest of the meeting minutes in project 1 and project 2. 4.8 SUMMARY Through this section the author presented the goals, scope, approach, and methodology of the research. The four major sections in which this thesis is divided is also presented, these sections are development and modifications of metrics from literature, automation of these metrics, development of web-based tool to report on bottlenecks, interviews, and discussion of feedbacks. The researcher through this section, has also presented the detailed flow chart of each step followed in this research. Lastly, the author presented the details of the inputs and outputs of the tool and details about the python coding performed. 63 CHAPTER 5 RESULTS This section discusses the usability of the web-tool and discusses the interview findings while also discussing the major changes made in the tool based on the interviewee feedbacks. A Qualitative Analysis is performed of the usability test given the sample size of interview is small and their feedback is used to continuously improve the tool and a comparative study between the initial and final stages of the tool is presented in section 6.3.2. 5.1 INTERVIEW FINDINGS The get feedback on the usability and adaptability of the tool in AEC teams, the researchers conducted two interviews with industry specialists. Interview Findings and Feedback: Through this section the researcher discusses the details of the two interviews which were arranged to discuss and get feedback from AEC project experts about the tool the researcher developed. The questions were designed to address three main questions: 1. The usability of the tool in AEC projects. 2. The adaptability of the tool within AEC teams. 3. The future directions to make the tool even more feasible and easier for use in AEC projects. Interview 1: Expansion Project in Midwest USA The interviewee suggested the tool offers great value when studying the project after a particular phase or towards the end in lessons learnt. The tool can help the Project Managers 64 understand what can be improved in team communications and information shared so that in next project these issues can be tackled. The interviewee appreciated the formatting, and content of the tool. One comment was to use homogenous color in the columns of bottleneck reporting table to maintain consistency. The interviewee also recognized the content of the tool was accurate and easy to understand. For future studies, the interviewee suggested to make the prediction real time could be of great use the Project Manager in AEC teams. This real-time simulation of ongoing bottlenecks can help the project manager to study the information trends, be pro-active and intervene, therefore helping with the resolution of the information bottlenecks before it happens. The real-time simulation can be achieved by merging the tool with project documentation software, so that all information bits are tied together in one application and tracking becomes less tedious. The contents of the web-based tool require data set which are usually available to project teams in all types of projects. Although, the formatting of the dataset could vary depending on the type of the project. The researcher received positive feedback regarding the general adaptability of the tool based on the type of dataset used. The interviewee was familiar with the information trend related information so, the navigation became easier and was received well. Interview 2: Renovation Project in Midwest USA The second interviewee appreciated the value of the tool in studying the project after completion. According to the subject, some issues which were reported could be managed better in subsequent projects using this tool. The subject also suggested the tool can be used 65 on a monthly/annual basis by the project managers to study any issues which might have skipped their attention. The subject highlighted this tool could be very useful for the AEC teams when studying their project for in-depth analysis. The interviewee suggested one way to improve the usability of the project is to use industry specific terms instead of research words. The activity type definitions (Pooled, Sequential, Reciprocal, and Intensive) could be simplified to help the project managers better understand the issues on hand. The subject gave positive feedback on the formatting, clarity, ease of navigation and content of the tool. The interviewee expressed concern on whether such detail of information could be available for all the projects. Since all construction projects are different in terms of size, scope, and budget. Projects with lower budget might have detailed documentation available. Therefore, the subject suggested this tool could be useful when multiple parties are involved, and project documentation is agreed prior to implementation. Therefore, the ease of adaptability of the tool for smaller budgeted projects could be different to that of high-end projects. The subject gave positive feedback on information trend metrics such as productivity, average days to resolve, and bottleneck prediction. The interviewee also believed the tool would have helped them study and manage the project better if it was available during the life cycle of the project. The major feedback on improving the tool was through using simpler terms so that it is more comprehensive for AEC team members. 66 5.2. INTERVIEW FEEDBACK AND MODIFICATIONS IN THE TOOL The following table 6.3 discusses in detail each of the feedback provided by the interviewee which participated in the project and then compares the initial and final screenshot of the tool . TABLE 6.3: COMPARISON BETWEEN INITIAL AND FINAL SCREENSHOT OF THE WEB-BASED TOOL Interview 1 Feedback 1: Increase the font size of the Definitions added to the homepage of the web- based tool. Initial Tool Screenshot: Tool after incorporating the Feedback 67 TABLE 6.3 (cont’d) Feedback 2: It is recommended to use homogenous colors through the diagrams in the model to help the user track the model easily. Initial Tool Screenshot: Tool after incorporating the Feedback 68 TABLE 6.3 (cont’d) Feedback 3: The interviewer suggested that to make the model more useful, the tool can be made real-time so that, it can track information from the project documentation websites in real time and bottleneck predictions can be made for upcoming bottlenecks. Feedback 3 is incorporated in the future directions of work as it is currently beyond the scope of this research. Interview 2 Feedback 1: It is recommended to improve the definitions or the daigram to make it easier for the AEC construction individuals to understand certain terms which are more research centric. Initial Tool Screenshot: 69 TABLE 6.3 (cont’d) Tool after incorporating the Feedback Feedback 2: The interviewee expressed concern on whether such detail of information could be available for all the projects. Since, all construction projects are different in terms of size, scope, and budget. Projects with lower budget might have detailed documentation available. Therefore, the subject suggested this tool could be useful when multiple parties are involved, and project 70 TABLE 6.3 (cont’d) documentation is agreed prior to implementation. Therefore, the ease of adaptability of the tool for smaller budgeted projects could be different to that of high-end projects. Feedback 2 will be addressed in the future directions of work. 71 CHAPTER 6 CONCLUSIONS AND DISCUSSIONS 6.1 INTRODUCTION This chapter discusses the major findings through this research. Additionally, this chapter concludes the research by discussing its limitations, and provides scope for future research. 6.2 KEY FINDINGS The research develops a web-tool which reports bottlenecks in AEC projects using archival data. The tool also illustrates team performance and project performance metrics while providing directions and remedies for the bottlenecks occurred. The key findings of the tool are discussed below: 6.2.1 USABILITY AND ADAPTABILITY OF THE TOOL The web-based tool offers AEC teams a platform to track and record bottlenecks which occurred during the length of the project. This analysis along with future remedies to avoid such bottlenecks could be crucial for the project teams when discussing the key takeaways of the project. The results of the tool based on its usability and adaptability in AEC projects is discussed below: • The tool uses project documentation data which is readily available for project teams throughout the project duration, this makes the tool easier to use. • Since the tool is developed as a stand-alone application, it can be used with any system, as long as the data set required for the tool is available in the right format. Therefore, the tool could be highly adaptable in AEC projects. 72 • From the feedback received from the interviews, the tool offers a realistic and reliable method to identify and record on potential bottlenecks throughout the project duration. • The tool is not in real time simulation but presents and reports bottlenecks which have already occurred therefore, it can be used at the end of the project as lessons learnt from the particular project. • The bottleneck remedies section of the tool presents the user with the chance to study each type of bottleneck in detail to make sure such type of issues do not get carried in future projects. • The tool is also stand-alone application solely developed for the purpose to identify and report on bottlenecks. Therefore, it offers a good integration platform for all types of project information modes (Meeting Minutes, Project Documentation, email Exchange) with a user-friendly application to identify how information flow is tracked and bottlenecks can be tackled. 6.3 RESEARCH CONTRIBUTIONS This research contributes to the literature on bottlenecks identification and Lean Construction in the following ways: 1. Provides two new metrics: Productivity and Average Days of Issue Resolution for the issues discussed in the bi-weekly AEC Project Meetings. 2. Modifies existing information flow metrics DV and WIP and uses the modified definitions to identify and report Project Bottlenecks. 73 3. Segregates the issues discussed in meetings in 4 different types: Pooled, Sequential, Reciprocal, and Intensive based on the complexity and collaboration requirements of different issues. 4. Develops a stand-alone web-based tool to report on bottlenecks, which is a unique tool solely dedicated to study the bottlenecks which occur during the lifecycle of an AEC project. The tool reports on bottlenecks, studies information exchange patterns between different groups of the project and provides preventive remedies and feedbacks to the users as lessons learnt for future prospective projects. 5. Tests the usability and adaptability of the tool qualitatively by conducting two expert interviews and improves the tool based on their feedbacks. 6.4 LIMITATIONS One main limitation of the study is that the projects whose data was used were different in their scope. One was an expansion project while the other was a renovation project in mid- western USA. There have not been studies made to identify if information exchange patterns between team members varies with the size of the project. Other limitation is that the dataset used as an import for the web-based model requires it to be in a specific format based on the protocol developed during the research. These aspects can be addressed in future literature efforts. Additionally, the bottleneck reporting tool uses archival data for its analysis and since it is not merged to operate simultaneously with project documentation websites these projects used, the reporting is not in real-time. 74 The following can be defined as the limitations of this study: 1. The quantitative tests on the usability of the tool could not be performed given the limitations of the sample size of the interviewees. For most quantitative analysis of usability and adaptability of web-tools and interfaces more than 12 participants are required. 2. The research uses dataset for two projects in Midwest USA only. 3. The simulation and codes developed by the researcher are not in real-time. The study uses archival datasets and reports, provides recommendations on bottlenecks which have already occurred. 6.5 DIRECTION FOR FUTURE RESEARCH The author provides the following directions of future work for this area: 1. The code developed by the researcher could be used by merging it with any project documentation website which then provides the chance for the users to identify and study project bottlenecks in real-time and not using archival datasets. 2. Quantitative Analysis of the tool could be performed by increasing the sample size of the interviews and performing certain tests like Cronbach Alpha. 3. Artificial Intelligence can be used to automatically read and extract data from the meeting minutes which can save the developer a lot of time and make it easier for the users. To accomplish this direction, a beta version of the tool is currently being planned. 4. The model can be expanded to incorporate wider audience and expertise than just focusing on construction projects only. The web-based tool can be generalized to 75 incorporate industrial, mechanical, and software projects so that the scope of the tool is improved. 5. Work can be done in the future to merge this web-based too with document management tools like Procore, Unifier so that transfer of information is in real time. 6.6 CONCLUSION The primary objective of the research was to develop and study the usability and adaptability of a web-based tool dedicated to study and report on bottlenecks which occur during the life cycle of a AEC project. This was successfully achieved by a combination of Literature review, metrics development and modifications, coding, expert interviews, and modifications in code based on the feedback. The data collected was analyzed quantitatively and used to study information exchange patterns, which helped in identifying bottlenecks. The findings of the research showed promising signs that such a tool can be adopted by AEC teams and by Project Managers to study their projects in detail and avoid issues and bottlenecks which could impact on cost or schedule. 76 APPENDIX 77 APPENDIX A: INTERVIEW PROTOCOL Interview and Survey Questions for Web-Based Tool to Predict Information Bottlenecks Study Number “STUDY00001064: Network Interventions on Engineering Projects” The purpose of this document is to provide an outline to the purpose and goals of this study, provide a transcript of the interview questions, and introduce the survey questions which will be used to study the usability of the platform. This report is submitted to IRB as a requirement before conducting interview with industry experts involved with this project. 1. Introduction: This interview and survey is performed as a part of my thesis ‘Understanding the Usability of Web-Based Tool in Identifying Information Bottlenecks in AEC Projects’. Through my thesis, I have a developed a web-based tool which imports archival data in the form of project documentation and uses this data to identify which timeframe has high probability of occurrence of bottleneck. Following the development, I want the usability of this tool in AEC projects by interviewing two AEC project personnel to get their feedback and suggested improvements. 2. Content for the Interview: The interview will be conducted via zoom. The interview will be recorded by asking the permission of the interviewees. This would help me to record their insights and use it as suggestions for improving the tool. The tool will be opened in my system with screen control provided to the interviewees. They will be allowed to browse and navigate through the tool. Since, the interview will be recorded, they can add their inputs throughout the length of the 78 meeting and their feedback will be transcribed after the meeting is over. Once transcribed, the feedback document will be sent to the interviewees to get their consent with the transcription. This document will then be used by the researcher to be included in the results section of the thesis. 3. Interview Transcript: I will be meeting Project Managers of the two projects I have been working closely with for the past two years. Here is the general format of the transcription of the interview to be conducted. • Hello Mr. A, My name is Pandey, I have been working on your project collecting and analyzing archival data for the past 2 years. For my thesis, using this archival data I came up with a tool. Today I want to show you this tool, allow you to navigate, So I can get your feedback about the usability and adaptability of this tool in AEC projects. • Based on the consent form, I will also be recording this meeting, This will help me not to miss out on any valuable input from your end. After the meeting, I will be forwarding you a document which summarizes all your feedback and our discussions today for your review and approval. Once approved, I can use the findings of this document in my thesis results. Any of the feedback or data that I have shared will remain confidential. • The screenshot of the web-based tool has been attached with this protocol: 79 FIGURE A: INFORMATION EXCHANGE AND ISSUES INFORMATION FIGURE B: AVERAGE DAYS TO COMPLETE AND PRODUCTIVITY • Here are a list of questions which you can answer after you are done navigating the tool: o Do you think this a useful tool? If so, at what frequency and who do you think should be using this? 80 o How do you think this tool can be improved so, it is more beneficial for the AEC teams? o Did you feel the content used in the web-based tool is arranged in the right format? o On a scale of 1-10 how do you rate the clarity of the content? Do you think this information is accurate /representative of your experience with the project? o Do you have other reflections on this tool, which you think could be useful? o Do you think this information is accurate /representative of your experience with the project? o In the projects you have worked on so far, is this technique of identification of information bottlenecks looks applicable? If so, who do you think is suitable to use this identification technique? o On a scale of 1-10 what is your understanding of information exchange trends in project teams after the presentation? o On a scale of 1-10, how do you rate the overall experience? o If you had this tool, do you think this would have been useful in identifying the information bottlenecks? o Were you able to navigate to other pages easily? o Do you have additional comments/recommendations to make the webpage even more user friendly? 81 APPENDIX B: PYTHON CODE import dash import dash_bootstrap_components as dbc import dash_core_components as dcc import dash_html_components as html from dash.dependencies import Input, Output, State from datetime import date import pandas as pd import base64 import datetime import io import dash from dash.dependencies import Input, Output, State import dash_core_components as dcc import dash_html_components as html import dash_table from datetime import date import dash import dash_html_components as html import dash_core_components as dcc import re import plotly.graph_objs as go from plotly.subplots import make_subplots import pandas as pd from dash.dependencies import Input, Output from dash.exceptions import PreventUpdate import plotly.express as px import dash_bootstrap_components as dbc import datetime import pandas as pd df = pd.read_excel(r'C:\Users\nishc\Documents\data.xlsx',sheet_name = 'Sheet2') df['Start Month']=df['Start Date'].dt.month df['End Month']=df['End Date'].dt.month df['End Year']=df['End Date'].dt.year df['Start Year']=df['Start Date'].dt.year #-----------email and issue file FIGURE C: PYTHON CODE 82 FIGURE C (cont’d) df1 = pd.read_excel(r'C:\Users\nishc\Documents\data.xlsx',sheet_name = 'Sheet3') df100 = df1 # ----------------------- df100['upcoming_meeting_date'] = df100['Meeting Date'].shift(periods=- 1) df100['days_between_meeting']=df100['upcoming_meeting_date']- df100['Meeting Date'] df100['firstcount']=(df100['Emails to D']+df100['Email to O']+df100['E mail to GC']+df100['PlanGrid']+df100['Unifier']) df100['secondcount']=df100['firstcount'].shift(periods=1) df100['days_between_meeting']=df100['days_between_meeting'].astype('st r') def func1(x): x=x[:2] return x df100['num_of_days']=df100.apply(lambda x: func1(x['days_between_meeti ng']), axis=1) df100['num_of_days']=df100['num_of_days'].replace('Na',0) df100['secondcount']=df100['secondcount'].fillna(0) df100['secondcount']=df100['secondcount'].astype('int') df100['num_of_days']=df100['num_of_days'].astype('int') df100['dv']=(df100['firstcount']- df100['secondcount'])/df100['num_of_days'] df100['dv']=df100['dv'].replace(df100['dv'][0],0) df100['sum_of_issues']=(df100['Issues to O']+df100['Issues to GC']+df1 00['Issues to D']) df100['sum_of_issues']=df100['sum_of_issues'].fillna(0) df100['sum_of_issues']=df100['sum_of_issues'].astype('int') df100['sum_of_issues_second_meet']=df100['sum_of_issues'].shift(period s=1) df100['WIP']=(df100['sum_of_issues']- df100['sum_of_issues_second_meet']) df100['WIP']=df100['WIP'].fillna(0) df100['Month']=df100['Meeting Date'].dt.month df1001=df100[['Meeting Date','upcoming_meeting_date','dv','WIP','Month ']] # -------------------------- # df1 = df1.rename(columns={'Issues to D':'Issues to D', 'Issues to O ':'Issues to O','Issues to GC':'Issues to GC','Emails to D':'Emails to D'}) df1['Start Date'] = df1['Meeting Date'] df5 = df.merge(df1, how='inner', on='Start Date') 83 FIGURE C (cont’d) abc = df5 group = df5.groupby(['Description','Responsible Party','Start Date','E nd Date','Days to Complete','Start Year','Start Month','End Year','End Month'])[['Emails to D','Issues to D','Email to O','Issues to O','Ema il to GC','Issues to GC']].sum().reset_index() #-----------type of issues----------------- df15 = pd.read_excel(r'C:\Users\nishc\Documents\data.xlsx',sheet_name= 'Types of Issues') df16=df15[['Recirpocal']] df16=df16.dropna() df16['name']='Recirpocal' df16.columns=['Description', 'name'] df17=df15[['Pooled']] df17=df17.dropna() df17['name']='Pooled' df17.columns=['Description', 'name'] df18=df15[['Intensive']] df18=df18.dropna() df18['name']='Intensive' df18.columns=['Description', 'name'] df19=df15[['Sequential']] df19=df19.dropna() df19['name']='Sequential' df19.columns=['Description', 'name'] df20 =pd.concat([df16,df17,df18,df19],axis=0) df19.columns=['Description', 'name'] df21=df.merge(df16,how = 'inner',on='Description') df22=df.merge(df17,how = 'inner',on='Description') df23=df.merge(df18,how = 'inner',on='Description') df24=df.merge(df19,how = 'inner',on='Description') df26 = pd.concat([df21,df22,df23,df24],axis=0) df27=df26.groupby(['name','Start Month','Responsible Party', 'End Mont h'])[['Description']].count().reset_index() print(df27.head(1)) external_stylesheets = 'bootstrap.css' app = dash.Dash(external_stylesheets=[dbc.themes.JOURNAL]) app.config['suppress_callback_exceptions'] = True app.config.suppress_callback_exceptions = True app.css.config.serve_locally = True 84 FIGURE C (cont’d) app.scripts.config.serve_locally = True server = app.server layout_1 = dbc.Container([ dbc.Row([ dbc.Col([ html.I('Start Year'), dcc.Dropdown(id='input1', multi=False, value=2019,options= [{'label':x, 'value':x} for x in sorted(group['Start Year']. unique())])],width={'size':2}), dbc.Col([ html.I('Start Month'), dcc.Dropdown(id='input2', multi=False, value=1,options=[{' label':x, 'value':x} for x in sorted(group['Start Month'] .unique())])],width={'size':2}), dbc.Col([ html.I('End Year'), dcc.Dropdown(id='input3', multi=False, value=2019,options= [{'label':x, 'value':x} for x in sorted(group['End Year'].un ique())] )],width={'size':2}), dbc.Col([ html.I('End Month'), dcc.Dropdown(id='input4', multi=False, value=1,options=[{' label':x, 'value':x} for x in sorted(group['End Month'].u nique())])],width={'size':2}), ], no_gutters=False, justify='start',style = {"padding": "2rem 0rem"}), dbc.Row([ dbc.Col([dcc.Loading(dcc.Graph(id='output', figure={},style = {"border":"10px groove"} ,)),],width={'size':6}), dbc.Col([dcc.Loading(dcc.Graph(id='output7', figure={},style = {"border":"10px groove"} ,)),],width={'size':6}) ])], fluid=True,style = {"padding": "2rem 0rem"} ) 85 FIGURE C (cont’d) layout2 = dbc.Container([ dbc.Row([ dbc.Col([ html.I('Start Year'), dcc.Dropdown(id='input1', multi=False, value=2019,options= [{'label':x, 'value':x} for x in sorted(group['Start Year']. unique())])],width={'size':2}), dbc.Col([ html.I('Start Month'), dcc.Dropdown(id='input2', multi=False, value=1,options=[{' label':x, 'value':x} for x in sorted(group['Start Month'] .unique())])],width={'size':2}), dbc.Col([ html.I('End Year'), dcc.Dropdown(id='input3', multi=False, value=2019,options= [{'label':x, 'value':x} for x in sorted(group['End Year'].un ique())] )],width={'size':2}), dbc.Col([ html.I('End Month'), dcc.Dropdown(id='input4', multi=False, value=1,options=[{' label':x, 'value':x} for x in sorted(group['End Month'].u nique())])],width={'size':2}), ], no_gutters=False, justify='start',style = {"padding": "2rem 0rem"}), # dbc.Row([ # dbc.Col([dcc.Loading(dcc.Graph(id='output', figure={},style = {"border":"10px groove"} ,)),],width={'size':12}) # ]), dbc.Row([ dbc.Col([dcc.Loading(dcc.Graph(id='output5', figure={},style = {"border":"10px groove"} ,)),],width={'size':12}) ], no_gutters=False, justify='start',style = {"padding": "2rem 0rem"})], fluid=True) 86 FIGURE C (cont’d) layout3 = dbc.Container([ dbc.Row([ dbc.Col([ html.I('Meeting Month'), dcc.Dropdown(id='input5', multi=False, value=2,options=[{' label':x, 'value':x} for x in sorted(group['Start Month'] .unique())])],width={'size':2}), ], no_gutters=False, justify='start',style = {"padding": "2rem 0rem"}), dbc.Row([ dbc.Col([dcc.Loading(dcc.Graph(id='output3', figure={},style = {"border":"10px groove"} ,)),],width={'size':6}), dbc.Col([dcc.Loading(dcc.Graph(id='output4', figure={},style = {"border":"10px groove"} ,)),],width={'size':6}) ], no_gutters=False, justify='start',style = {"padding": "2rem 0rem"}) ], fluid=True) navbar = dbc.NavbarSimple( children=[ dbc.Button("☰", outline=True, color="secondary", className="mr -1", id="btn_sidebar"), # dbc.NavItem(dbc.NavLink("Page 1", href="#")), # dbc.DropdownMenu( # children=[ # dbc.DropdownMenuItem("More pages", header=True), # dbc.DropdownMenuItem("Page 2", href="#"), # dbc.DropdownMenuItem("Page 3", href="#"), # ], # nav=True, # in_navbar=True, # label="More", # ), ], brand="Bottleneck Dectection tool", brand_href="#", color="dark", dark=True, 87 FIGURE C (cont’d) fluid=True, ) layout4 = dbc.Container([ dbc.Row([ dbc.Col([ html.I('Start Year'), dcc.Dropdown(id='input1', multi=False, value=2019,options= [{'label':x, 'value':x} for x in sorted(group['Start Year']. unique())])],width={'size':2}), dbc.Col([ html.I('Start Month'), dcc.Dropdown(id='input2', multi=False, value=1,options=[{' label':x, 'value':x} for x in sorted(group['Start Month'] .unique())])],width={'size':2}), dbc.Col([ html.I('End Year'), dcc.Dropdown(id='input3', multi=False, value=2019,options= [{'label':x, 'value':x} for x in sorted(group['End Year'].un ique())] )],width={'size':2}), dbc.Col([ html.I('End Month'), dcc.Dropdown(id='input4', multi=False, value=1,options=[{' label':x, 'value':x} for x in sorted(group['End Month'].u nique())])],width={'size':2}), ], no_gutters=False, justify='start',style = {"padding": "2rem 0rem"}), dbc.Row([ dbc.Col([dcc.Loading(dcc.Graph(id='output1', figure={},style = {"border":"10px groove"} ,)),],width={'size':6}), dbc.Col([dcc.Loading(dcc.Graph(id='output2', figure={},style = {"border":"10px groove"} ,)),],width={'size':6}) 88 FIGURE C (cont’d) ], no_gutters=False, justify='start',style = {"padding": "2rem 0rem"}) ], fluid=True) # the style arguments for the sidebar. We use position:fixed and a fix ed width SIDEBAR_STYLE = { "position": "fixed", "top": 62.5, "left": 0, "bottom": 0, "width": "16rem", "height": "100%", "z-index": 1, "overflow-x": "hidden", "transition": "all 0.5s", "padding": "0.5rem 1rem", "background-color": "#f8f9fa", } SIDEBAR_HIDEN = { "position": "fixed", "top": 62.5, "left": "-16rem", "bottom": 0, "width": "16rem", "height": "100%", "z-index": 1, "overflow-x": "hidden", "transition": "all 0.5s", "padding": "0rem 0rem", "background-color": "#f8f9fa", } # the styles for the main content position it to the right of the side bar and # add some padding. CONTENT_STYLE = { "transition": "margin-left .5s", "margin-left": "17rem", "margin-right": "1rem", "padding": "1rem 1rem", 89 FIGURE C (cont’d) "background-color": "#f8f9fa", } CONTENT_STYLE1 = { "transition": "margin-left .5s", "margin-left": "1rem", "margin-right": "1rem", "padding": "1rem 1rem", "background-color": "#f8f9fa", } date =date.today() sidebar = html.Div( [ # html.H2("Sidebar", className="display-4"), html.I('Date :: {}'.format(date)), html.Hr(), # html.P( # "A simple sidebar layout with navigation links", classNa me="lead" # ), dbc.Nav( [ dbc.NavLink("Information Trend", href="/page- 1", id="page-1-link"), dbc.NavLink("Issue Report", href="/page-2", id="page- 2-link"), dbc.NavLink("WIP & DV", href="/page-3", id="page-3- link"), dbc.NavLink("Avg Days to Complete & Productivity", hre f="/page-4", id="page-4-link"), # dbc.NavLink("WIP", href="/page-3", id="page-5- link"), # dbc.NavLink("DV", href="/page-3", id="page-6-link"), ], vertical=True, pills=True, ), ], id="sidebar", style=SIDEBAR_STYLE, ) content = html.Div( 90 FIGURE C (cont’d) id="page-content", style=CONTENT_STYLE) app.layout = html.Div( [ dcc.Store(id='side_click'), dcc.Location(id="url"), navbar, sidebar, content, ], ) @app.callback( [ Output("sidebar", "style"), Output("page-content", "style"), Output("side_click", "data"), ], [Input("btn_sidebar", "n_clicks")], [ State("side_click", "data"), ] ) def toggle_sidebar(n, nclick): if n: if nclick == "SHOW": sidebar_style = SIDEBAR_HIDEN content_style = CONTENT_STYLE1 cur_nclick = "HIDDEN" else: sidebar_style = SIDEBAR_STYLE content_style = CONTENT_STYLE cur_nclick = "SHOW" else: sidebar_style = SIDEBAR_STYLE content_style = CONTENT_STYLE cur_nclick = 'SHOW' return sidebar_style, content_style, cur_nclick # this callback uses the current pathname to set the active state of t he 91 FIGURE C (cont’d) # corresponding nav link to true, allowing users to tell see page they are on @app.callback( [Output(f"page-{i}-link", "active") for i in range(1, 4)], [Input("url", "pathname")], ) def toggle_active_links(pathname): if pathname == "/": # Treat page 1 as the homepage / index return True, False, False return [pathname == f"/page-{i}" for i in range(1, 4)] @app.callback(Output("page- content", "children"), [Input("url", "pathname")]) def render_page_content(pathname): if pathname in ["/", "/page-1"]: return [layout_1] elif pathname == "/page-2": return [layout2] elif pathname == "/page-3": return [layout3] elif pathname == "/page-4": return [layout4] # If the user tries to reach a different page, return a 404 messag e return dbc.Jumbotron( [ html.H1("404: Not found", className="text-danger"), html.Hr(), html.P(f"The pathname {pathname} was not recognised..."), ] ) @app.callback( Output("output", "figure"), Input("input1", "value"), Input("input2", "value"), Input("input3", "value"), Input("input4", "value"), ) def func(start_year,start_month,end_year,end_month): df = group[(group['Start Year']==start_year)&(group['End Year']==e nd_year)&(group['Start Month']==start_month)&(group['End Month']==end_ month)] 92 FIGURE C (cont’d) dff =pd.melt(df, id_vars=['Description','Responsible Party','Start Year','Start Month','End Year','End Month','Start Date','End Date','D ays to Complete'], var_name=[('Emails to D','Issues to D','Email to O' ,'Issues to O','Email to GC','Issues to GC')], value_name='value') dff.columns = ['Description','Responsible Party','Start Year','Sta rt Month','End Year','End Month','Start Date','End Date','Days to Comp lete','colnames','value'] dff = dff[(dff['colnames']!='Issues to D')&(dff['colnames']!='Issu es to O')&(dff['colnames']!='Issues to GC')] dff=dff.groupby(['Description','Responsible Party','Start Month',' End Month','Start Year','End Year','colnames'])[['value']].sum().reset _index() return px.bar(dff, x='colnames', y='value',template = 'plotly_dark ',color='Description',title='Email Information', height=480)\ .update_layout(showlegend=True,margin=dict(t=50, b=50, l=50, r=50) ,title_x=0.5,xaxis=dict(title=dict(text='Responsible Party',font=dict( size=14)))) @app.callback( Output("output7", "figure"), Input("input1", "value"), Input("input2", "value"), Input("input3", "value"), Input("input4", "value"), ) def func(start_year,start_month,end_year,end_month): df = group[(group['Start Year']==start_year)&(group['End Year']==e nd_year)&(group['Start Month']==start_month)&(group['End Month']==end_ month)] dff =pd.melt(df, id_vars=['Description','Responsible Party','Start Year','Start Month','End Year','End Month','Start Date','End Date','D ays to Complete'], var_name=[('Emails to D','Issues to D','Email to O' ,'Issues to O','Email to GC','Issues to GC')], value_name='value') dff.columns = ['Description','Responsible Party','Start Year','Sta rt Month','End Year','End Month','Start Date','End Date','Days to Comp lete','colnames','value'] dff = dff[(dff['colnames']!='Emails to D')&(dff['colnames']!='Emai l to O')&(dff['colnames']!='Email to GC')] dff=dff.groupby(['Description','Responsible Party','Start Month',' End Month','Start Year','End Year','colnames'])[['value']].sum().reset _index() return px.bar(dff, x='colnames', y='value',template = 'plotly_dark ',color='Description',title='Issue Information', height=480)\ 93 FIGURE C (cont’d) .update_layout(showlegend=True,margin=dict(t=50, b=50, l=50, r=50) ,title_x=0.5,xaxis=dict(title=dict(text='Responsible Party',font=dict( size=14)))) @app.callback( Output("output5", "figure"), Input("input2", "value"), Input("input4", "value"), ) def func1011(startmonth,endmonth): df28=df27[(df27['Start Month']==startmonth)&(df27['End Month']==en dmonth)] return px.bar(df28, x='name', y='Description',color = 'Responsible Party',template = 'plotly_dark',title='Issue Report', height=480)\ .update_layout(showlegend=True,margin=dict(t=50, b=50, l=50, r=50) ,title_x=0.5,xaxis=dict(title=dict(text='Types of Issues',font=dict(si ze=14)))) @app.callback( Output("output3", "figure"), Input("input5", "value"), ) def func100(month): df12=df1001[df1001['Month']==month] return px.bar(df12, x='Meeting Date', y='WIP',color = 'Meeting Dat e',template = 'plotly_dark',title='WIP', height=480)\ .update_layout(showlegend=True,margin=dict(t=50, b=50, l=50, r=50) ,title_x=0.5) @app.callback( Output("output4", "figure"), Input("input5", "value"), ) def dv(month): df12=df1001[df1001['Month']==month] return px.bar(df12, x='Meeting Date', y='dv',color = 'Meeting Date ',template = 'plotly_dark',title='DV', height=480)\ .update_layout(showlegend=True,margin=dict(t=50, b=50, l=50, r=50) ,title_x=0.5) @app.callback( Output("output1", "figure"), Input("input1", "value"), Input("input2", "value"), Input("input3", "value"), 94 FIGURE C (cont’d) Input("input4", "value"), ) def func1(start_year,start_month,end_year,end_month): owner = abc[(abc['Responsible Party']=='O')&(abc['Start Year']==st art_year)&(abc['End Year']==end_year)&(abc['Start Month']==start_month )&(abc['End Month']==end_month)] owner=owner[['Responsible Party','Email to O','Issues to O','Days to Complete']] owner['average_days_to_complete']=owner['Days to Complete'].mean() owner['total_email']=owner['Email to O'].sum() owner['email']=owner['Issues to O'].sum() owner['productivity'] = (owner['email']/owner['total_email'])*100 owner =owner[['Responsible Party','total_email','productivity','a verage_days_to_complete']] owner=owner[0:1] gc = abc[(abc['Responsible Party']=='GC')&(abc['Start Year']==star t_year)&(abc['End Year']==end_year)&(abc['Start Month']==start_month)& (abc['End Month']==end_month)] gc=gc[['Responsible Party','Email to GC','Issues to GC','Days to C omplete']] gc['average_days_to_complete']=gc['Days to Complete'].mean() gc['total_email']=gc['Email to GC'].sum() gc['email']=gc['Issues to GC'].sum() gc['productivity'] = (gc['email']/gc['total_email'])*100 gc =gc[['Responsible Party','total_email','productivity','average _days_to_complete']] gc=gc[0:1] d = abc[(abc['Responsible Party']=='D')&(abc['Start Year']==start_ year)&(abc['End Year']==end_year)&(abc['Start Month']==start_month)&(a bc['End Month']==end_month)] d=d[['Responsible Party','Emails to D','Issues to D','Days to Comp lete']] d['average_days_to_complete']=d['Days to Complete'].mean() d['total_email']=d['Emails to D'].sum() d['email']=d['Issues to D'].sum() d['productivity'] = (d['email']/d['total_email'])*100 d =d[['Responsible Party','total_email','productivity','average_d ays_to_complete']] d=d[0:1] frames = [owner, d, gc] result = pd.concat(frames) # pie_fig = px.pie(result, names=result['Responsible Party'], valu es='average_days_to_complete' ,height = 480,hole = .3,template = 'plot ly_dark',color = 'Responsible Party' , title='Average Days to Complete ')\ 95 FIGURE C (cont’d) # .update_layout(showlegend=True,margin=dict(t=50, b=50, l =50, r=50),title_x=0.5).update_traces(textposition='inside', textinfo ='label+percent+value') # return pie_fig return px.bar(result, x='Responsible Party', y='average_days_to_co mplete',color = 'Responsible Party',template = 'plotly_dark',title='Av erage Days to Complete', height=480)\ .update_layout(showlegend=True,margin=dict(t=50, b=50, l=50, r=50) ,title_x=0.5) @app.callback( Output("output2", "figure"), Input("input1", "value"), Input("input2", "value"), Input("input3", "value"), Input("input4", "value"), ) def func3(start_year,start_month,end_year,end_month): owner1 = abc[(abc['Responsible Party']=='O')&(abc['Start Year']==s tart_year)&(abc['End Year']==end_year)&(abc['Start Month']==start_mont h)&(abc['End Month']==end_month)] owner1=owner1[['Responsible Party','Email to O','Issues to O','Day s to Complete']] owner1['average_days_to_complete']=owner1['Days to Complete'].mean () owner1['total_email']=owner1['Email to O'].sum() owner1['email']=owner1['Issues to O'].sum() owner1['productivity'] = (owner1['email']/owner1['total_email'])*1 00 owner1 =owner1[['Responsible Party','total_email','productivity', 'average_days_to_complete']] owner1=owner1[0:1] gc1 = abc[(abc['Responsible Party']=='GC')&(abc['Start Year']==sta rt_year)&(abc['End Year']==end_year)&(abc['Start Month']==start_month) &(abc['End Month']==end_month)] gc1=gc1[['Responsible Party','Email to GC','Issues to GC','Days to Complete']] gc1['average_days_to_complete']=gc1['Days to Complete'].mean() gc1['total_email']=gc1['Email to GC'].sum() gc1['email']=gc1['Issues to GC'].sum() gc1['productivity'] = (gc1['email']/gc1['total_email'])*100 gc1 =gc1[['Responsible Party','total_email','productivity','avera ge_days_to_complete']] gc1=gc1[0:1] 96 FIGURE C (cont’d) d1 = abc[(abc['Responsible Party']=='D')&(abc['Start Year']==start _year)&(abc['End Year']==end_year)&(abc['Start Month']==start_month)&( abc['End Month']==end_month)] d1=d1[['Responsible Party','Emails to D','Issues to D','Days to Co mplete']] d1['average_days_to_complete']=d1['Days to Complete'].mean() d1['total_email']=d1['Emails to D'].sum() d1['email']=d1['Issues to D'].sum() d1['productivity'] = (d1['email']/d1['total_email'])*100 d1 =d1[['Responsible Party','total_email','productivity','average _days_to_complete']] d1=d1[0:1] frames = [owner1, d1, gc1] result = pd.concat(frames) # pie_fig = px.pie(result, names=result['Responsible Party'], valu es='productivity' ,height = 480,hole = .3,template = 'plotly_dark',col or = 'Responsible Party' , title='Productivity')\ # .update_layout(showlegend=True,margin=dict(t=50, b=50, l =50, r=50),title_x=0.5).update_traces(textposition='inside', textinfo ='label+percent+value') # return pie_fig return px.bar(result, x='Responsible Party', y='productivity',colo r = 'Responsible Party',template = 'plotly_dark',title='Productivity', height=480)\ .update_layout(showlegend=True,margin=dict(t=50, b=50, l=50, r=50) ,title_x=0.5) if __name__ == "__main__": APPENDIX C: INTERVIEW FINDINGS Interview Findings and Feedback: Through this section the researcher discusses the details of the two interviews which were arranged to discuss and get feedback from AEC project experts about the tool the researcher developed. The questions were designed to address three main questions: 1. The usability of the tool in AEC projects. 97 2. The adaptability of the tool within AEC teams. 3. The future directions to make the tool even more feasible and easier for use in AEC projects. Interview 1: Expansion Project in Midwest USA The interviewee suggested the tool offers great value when studying the project after a particular phase or towards the end in lessons learnt. The tool can help the Project Managers understand what can be improved in team communications and information shared so that in next project these issues can be tackled. The interviewee appreciated the formatting, and content of the tool. One comment was to use homogenous color in the columns of bottleneck reporting table to maintain consistency. The interviewee also recognized the content of the tool was accurate and easy to understand. For future studies, the interviewee suggested to make the prediction real time could be of great use the Project Manager in AEC teams. This real-time simulation of ongoing bottlenecks can help the project manager to study the information trends, be pro-active and intervene, therefore helping with the resolution of the information bottlenecks before it actually happens. The real-time simulation can be achieved by merging the tool with project documentation software, so that all information bits are tied together in one application and tracking becomes less tedious. The contents of the web-based tool require data set which are usually available to project teams in all types of projects. Although, the formatting of the dataset could vary depending on the type of the project. The researcher received positive feedback regarding the general 98 adaptability of the tool based on the type of dataset used. The interviewee was familiar with the information trend related information so, the navigation became easier and was received well. Interview 2: Renovation Project in Midwest USA The second interviewee appreciated the value of the tool in studying the project after completion. According to the subject, some issues which were reported could be managed better in subsequent projects by the use of this tool. The subject also suggested the tool can be used on a monthly/annual basis by the project managers to study any issues which might have skipped their attention. The subject highlighted this tool could be very useful for the AEC teams when studying their project for in-depth analysis. The interviewee suggested one way to improve the usability of the project is to use industry specific terms instead of research words. The activity type definitions (Pooled, Sequential, Reciprocal, and Intensive) could be simplified to help the project managers better understand the issues on hand. The subject gave positive feedback on the formatting, clarity, ease of navigation and content of the tool. The interviewee expressed concern on whether such detail of information could be available for all the projects. Since, all construction projects are different in terms of size, scope, and budget. Projects with lower budget might have detailed documentation available. Therefore, the subject suggested this tool could be useful when multiple parties are involved, and project documentation is agreed prior to implementation. Therefore, the ease of adaptability of the tool for smaller budgeted projects could be different to that of high-end projects. 99 The subject gave positive feedback on information trend metrics such as productivity, average days to resolve, and bottleneck prediction. The interviewee also believed the tool would have helped them study and manage the project better if it was available during the life cycle of the project. The major feedback on improving the tool was through using simpler terms so that it is more comprehensive for AEC team members. APPENDIX D: EMAIL CLEANING PROTOCOL 1) There are two modes of extraction of emails. The email data should include received time, sender e-mail, receiver e-mail, sender name/surname, receiver name/surname, email subject line, email size, message ID, filenames of attached files a. Server i. Protocol to extract: 1. 'Sender' and 'Receiver' data per email include at least one individual from the attached roster (roster.xlsx) 2. 'Receiver' data per email includes at least two individuals from the roster, regardless of the sender. 3. The information we seek is a CSV file with each row representing an email with headers - sender email address, receiver email addresses, subject, timestamp, and email size. A sample excel file is attached ('sample_template.xlsx'). 4. Please do not eliminate non-consenting individuals. We are supposed to strike them out per the study protocol. ii. Cleaning emails using subject lines: use step 1 below for small datasets and step 2 for large datasets 1. Manual: line-by-line delete irrelevant emails as deduced from subject lines 2. Automation: prepare a set of whitelisted subject line words that are relevant to the project (name of project, contractors, keywords such as construction etc.); delete all emails that does not contain at least one whitelisted word in the subject line b. Personal Laptops i. Protocol to extract: run the macro on folders relevant to the project ii. In the absence of folders relevant to project run Step 1.a.ii.2 on the extracted emails 2) Prepare a diary of all unique individuals appearing in the emails, accounting for duplicate names and emails of the same individual. Label this file diary.xlsx. This file 100 would be of the format where each row corresponds to a unique individual. ‘ID’ represents a unique individual, ‘e1’, ‘e2’,… are email addresses with which the person appear in the email dataset and ‘n1’, ‘n2’,… are names with which the person appear in the email dataset. Clean the diary by keeping only individuals that are relevant to the project in the ID. Others such as marketing, group-emails, relatives constitute blacklisted emails/names. ID e1 e2 n1 n2 3) Remove duplicate emails based on emails that have duplicated received time, sender ID, and formatted subject line (formatted subject lines are subject lines after removing prefixes such as Re:, Fwd:, [EXTERNAL] etc. 4) Prepare a final cleaned email communication dataset in the format date size subject sender receiver receiver ….. received ID 1 ID 2 ID last ID 5) To obtain edge weight for a given pair of nodes in a given date range of interest: a. Find the number of emails exchanged between the pair in the given date range b. Find the number of business days, business weeks, and business months in that date range c. Edge weight is 3, 2, and 1 respectively if the number of emails exceed business days, business weeks, and business months; 0 otherwise 101 APPENDIX E: IRB APPROVAL LETTER 102 103 104 105 106 APPENDIX F: EXAMPLE OF IDENTIFICATION OF ISSUE TYPE. This appendix discusses and provides an example of how each issue type is decided based on the activity discussed in the project meetings. The four types of issues are pooled, sequential, reciprocal, and intensive. They can be defined as: i. Pooled: Pooled issues are least interdependent where work and activities is distributed separately by members of the team. This type of interdependency is common for low complexity tasks and require minimal collaborations. ii. Sequential: In sequential issues work and tasks flow unidirectionally between team members based on their expertise. Usually, collaboration is not required as information follows its defined path based on the functionality of the team members. Sequential type issues are also common for low complexity tasks. iii. Reciprocal: Reciprocal issues are those which involves back and forth of information between team members till the issue is resolved. Usually, team members of two different expertise coordinate closely to resolve such issues and thus it involves large amount of information and communication. Such issues are common for high complexity tasks which requires rechecks, and reworks. iv. Intensive: Intensive issues are usually of highest complexity. Due to their complexity, there is often no regular pattern which is followed by team members. Such issues 107 are goal oriented, and the project teams of various expertise collaborate for their resolution. Intensive issues are usually high complexity tasks. Sample of Type of Issue discussed in project meeting: • GC to send work scope to Designer for Graphics package next week for monthly coordination meeting. – In this example, two parties GC and designer are involved in exchange of information. The package that will be sent is a transmittal rather than a submittal therefore, it does not require information to be sent back to the GC by the designer. The flow is unilateral and is flowing through a sequential manner, therefore this issue is Sequential in manner. • GC reviewed their concept estimate that was provided, based on meetings between the design team and GC, an initial concept estimate of @$ X million total project costs was shown based on best information available. After a number of CCL items were reviewed and approved, the current concept estimate indicates @$ Y M total project cost. A few items of note, related to contingencies; the current project costs noted above, includes no Design Contingency and a fixed Construction Contingency in the amount of $Z M. GC is still reviewing allowances and assumptions and will update the estimate over this phase. – For this example, it is clear to notice that since this is a budget related issue, more than 2 parties are involved in the process. For example, design team provides information to GC, GC gets other information from other potential sub-contractors and then provides that information to the owner of the project. Based on the comments received from the owner the GC re-coordinates and 108 changes the budget or cost associated with the project by further coordinating it with the designer and sub-contractors, therefore based on the definition of the issue types, this issue is intensive in nature as it requires information exchange and coordination between multiple parties and the information exchange is not unilateral in nature. 109 REFERENCES 110 REFERENCES Abdelhamid, T., Xi, L., & Everett, J. G. (2009). The Validity of Data Dependent System Modelling to Predict Relative Physiological Workload during Construction Work. In Construction Research Congress 2009: Building a Sustainable Future (pp. 705-715). Al Hattab, M., & Hamzeh, F. (2015). Using social network theory and simulation to compare traditional versus BIM–lean practice for design error management. Automation in construction, 52, 59-69. Al Hattab, M., & Hamzeh, F. (2018). Simulating the dynamics of social agents and information flows in BIM-based design. Automation in Construction, 92, 1-22. Aronson, J. E., Liang, T. P., & MacCarthy, R. V. (2005). Decision support systems and intelligent systems (Vol. 4). Upper Saddle River, NJ, USA: Pearson Prentice-Hall. Ashwini, C. R. Bottleneck Analysis and Standardized Lean Tool to Improve Productivity in Automotive Industry. Baldwin, A. N., Thorpe, A., & Carter, C. (1999). The use of electronic information exchange on construction alliance projects. Automation in construction, 8(6), 651-662. Bell, B. S., & Kozlowski, S. W. (2002). A typology of virtual teams: Implications for effective leadership. Group & organization management, 27(1), 14-49. Budiu, R. (2017). Quantitative vs. qualitative usability testing. Nielsen Norman Group, 1. Chang, A., & Ibbs, C. (1999). "Designing Levels for A/E Consultant Performance Measures". Project Management Journal, 30(4), 42-54. Dainty, A., Moore, D., & Murray, M. (2007). Communication in construction: Theory and practice. Routledge. Emmitt, S., & Gorse, C. (2006). Communication in construction teams. Routledge. Foley, J., & Macmillan, S. (2005). Patterns of interaction in construction team meetings. CoDesign, 1(1), 19-37. Fyall, M. (2002). When project information flow becomes turbulent: toward an organizational reynolds number (Vol. 138). CIFE: Center for Integrated Facility Engineering, Technical Report#138. Stanford University 111 Kozlowski, S. W., & Bell, B. S. (2019). Evidence-based principles and strategies for optimizing team functioning and performance in science teams. In Strategies for Team Science Success (pp. 269- 293). Springer, Cham. Marks, M.A. , Mathieu, J.E., & Zaccaro, S. J. (2001). A temporally based framework and taxonomy of team processes. Academy of management review, 26(3), 356-376. Nitithamyong, P., & Skibniewski, M. J. (2004). Web-based construction project management systems: how to make them successful?. Automation in construction, 13(4), 491-506. Sacks, R. (2016). What constitutes good production flow in construction?. Construction management and economics, 34(9), 641-656. Sacks, R., Koskela, L., Dave, B., and Owen, R. (2010). "Interaction of Lean and Building Information Modeling in Construction". Journal of Construction Engineering and Management, 136(9), 968- 980. Sacks, R., Seppänen, O., Priven, V., & Savosnick, J. (2017). Construction flow index: a metric of production flow quality in construction. Construction management and economics, 35(1-2), 45- 63. Schafer, D., Abdelhamid, T. S., Mitropoulos, P., & Howell, G. A. (2008, July). Resilience engineering: a new paradigm for safety in lean construction systems. In 16th Annual Conference of the International Group for Lean Construction, Manchester (pp. 16-18). Staron, M., & Meding, W. (2011, June). Monitoring bottlenecks in agile and lean software development projects–a method and its industrial use. In International Conference on Product Focused Software Process Improvement (pp. 3-16). Springer, Berlin, Heidelberg. Stewart, R. A., & Mohamed, S. (2004). Evaluating web-based project information management in construction: capturing the long-term value creation process. Automation in Construction, 13(4), 469-479. Sun, W. (2013). Factors influencing effective implementation of integrated project delivery in project team organizations as an innovation in the AEC industry. Michigan State University. Construction Management. Thomas, H. R., Horman, M. J., Minchin Jr, R. E., & Chen, D. (2003). Improving labor flow reliability for better productivity as lean construction principle. Journal of construction engineering and management, 129(3), 251-261. Tribelsky, E., & Sacks, R. (2007). “Measures of information flow for lean design in civil engineering.” Proceedings of CME 2007 Conference - Construction Management and Economics: 'Past, Present and Future', 1493–1504. 112 Tribelsky, E., & Sacks, R. (2010a). Measuring information flow in the detailed design of construction projects. Research in Engineering Design, 21(3), 189-206. Tribelsky, E., & Sacks, R. (2010b). The relationship between information flow and project success in multidisciplinary civil engineering design. Proceedings of the IGLC, Haifa, Israel, 14-16. Tribelsky, E., & Sacks, R. (2011). An empirical study of information flows in multidisciplinary civil engineering design teams using lean measures. Architectural Engineering and Design Management, 7(2), 85-101. Whitford D. & Cox J. (2016). "The Goal: A Process of Ongoing Improvement” 20051 Barrington, MA: North River Press 2004. 384 pp., ISBN: 0‐88427‐178‐1 3rd rev. ed. Wolniak, R., Skotnicka-Zasadzień, B., & Gębalska-Kwiecień, A. (2018). Identification of bottlenecks and analysis of the state before applying lean management. In MATEC Web of Conferences (Vol. 183, p. 01001). EDP Sciences. Zidane, Y. J., Johansen, A., Andersen, B., & Hoseini, E. (2015). Time-thieves and bottlenecks in the Norwegian construction projects. Procedia Economics and Finance, 21, 486-493. 113