Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Characterizing bottlenecks in building design coordination meetings Cavka, Hasan Burak 2010

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

Notice for Google Chrome users:
If you are having trouble viewing or searching the PDF with Google Chrome, please download it here instead.

Item Metadata


24-ubc_2010_spring_cavka_hasan_burak.pdf [ 1.54MB ]
JSON: 24-1.0062487.json
JSON-LD: 24-1.0062487-ld.json
RDF/XML (Pretty): 24-1.0062487-rdf.xml
RDF/JSON: 24-1.0062487-rdf.json
Turtle: 24-1.0062487-turtle.txt
N-Triples: 24-1.0062487-rdf-ntriples.txt
Original Record: 24-1.0062487-source.json
Full Text

Full Text

 CHARACTERIZING BOTTLENECKS IN BUILDING DESIGN COORDINATION MEETINGS   by  HASAN BURAK CAVKA B. Arch., Dokuz Eylul University, 1999   THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF  MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES  (CIVIL ENGINEERING)   THE UNIVERSITY OF BRITISH COLUMBIA (Vancouver)  APRIL 2010     © Hasan Burak Cavka, 2010    ii ABSTRACT This thesis describes an ethnographic field study that examined the design coordination process in two building projects.  The goal of the study was to better understand the challenges faced by project teams as they coordinate designs in multi- disciplinary meeting environments.  I focus on the bottlenecks encountered during in- person and distributed project coordination meetings. I observed meeting bottlenecks when meeting activities were performed inefficiently, when the meeting process was slowed down, when meeting workflow was interrupted, or when decision-making was hindered.  I identified and characterized meeting bottlenecks in a framework that illustrates the nature of the bottleneck, and the frequency of its occurrence.  According to my observations, there were two main categories of causes for bottlenecks in coordination meetings: context-based bottlenecks and content-based bottlenecks. Context-based bottlenecks are caused by the people in the design team, the meeting environment and the meeting technology. Content-based bottlenecks are related to the nature of the information artifacts (e.g., drawings and other design information) and the interactions with these artifacts (e.g., navigation and annotation). This study also provides an analysis of the frequency and patterns of various bottlenecks encountered in different meeting settings.  For example, in paper-based meetings, there were more “interaction/ access” bottlenecks observed since the meeting activities involved the use of information artifacts and the participants’ interaction with these artifacts. In distributed meetings, the larger number of meeting bottlenecks was observed under the “technology” bottlenecks group. Therefore, this analysis illustrates the specific requirements for different meeting settings. This study enhances our understanding of the work practice of project teams in design coordination meetings.  It highlights the many ways that meeting efficiency could be improved for design teams in coordination meetings. By using the vignettes in this study, people from different domains can understand the nature of the meeting processes, the techniques used by project teams when coordinating designs, and the different methods used by meeting participants to interact with information artifacts. My hope is that these findings will inform the design of new interaction, visualization, and integration technologies that better support the meeting processes of design teams.     iii TABLE OF CONTENTS ABSTRACT........................................................................................................................ ii TABLE OF CONTENTS................................................................................................... iii LIST OF TABLES...............................................................................................................v LIST OF FIGURES .......................................................................................................... vii ACKNOWLEDGEMENTS............................................................................................. viii CHAPTER 1: INTRODUCTION........................................................................................1 1.1Summary of Research Method..................................................................................2 1.2 Summary of Results.................................................................................................4 1.3 Outline of Thesis......................................................................................................5 CHAPTER 2: BACKGROUND ON STUDIED PROJECTS.............................................7 2.1 Information on Centre for Interactive Research and Sustainability (CIRS) ............7 2.1.1 CIRS Project Details .......................................................................................8 2.1.2 CIRS Coordination Meetings and Meeting Spaces ......................................10 2.2 Information on Energy Environment Experiential Learning (E.E.EL) Centre......12 2.2.1 EEEL Project Details ....................................................................................13 2.2.2 EEEL Coordination Meetings.......................................................................14 CHAPTER 3: METHODOLOGY .....................................................................................16 CHAPTER 4: CHARACTERIZATION OF DESIGN MEETING BOTTLENECKS......23 4.1 Context Based Bottlenecks ....................................................................................24 4.1.1 People.........................................................................................................24 4.1.2 Meeting Environment ................................................................................28 4.1.3 Technology ................................................................................................32    iv 4.2 Content Based Bottlenecks ....................................................................................39 4.2.1 Drawings ....................................................................................................39 4.2.2 Interaction/ Access.....................................................................................45 4.2.3 Information ................................................................................................57 4.3  Project Specific Bottlenecks (Ambiguity) ............................................................64 4.4 Representation and Interpretation of the Observational Data in the Bottlenecks Framework .............................................................................................................65 CHAPTER 5: LITERATURE REVIEW...........................................................................71 5.1 Meeting Bottlenecks ..................................................................................71 5.2 Interactive Work Spaces ............................................................................72 5.3 Workspace Activity ...................................................................................75 5.4 Artifact Use in Coordination and Design...................................................75 5.5 Mapping of Literature to my Framework ..................................................76 CHAPTER 6: CONCLUSIONS, RECOMMENDATIONS FOR FUTURE WORK.......78 REFERENCES ..................................................................................................................85              v LIST OF TABLES Table 1: Breakdown of the observed CIRS meetings........................................................12 Table 2: EEEL Centre Program .........................................................................................13 Table 3: Breakdown of the observed EEEL meetings .......................................................15 Table 4: Summary of research tasks ..................................................................................16 Table 5: Breakdown of the meetings observed..................................................................18 Table 6: Framework of the categorized meeting bottlenecks ............................................23 Table 7: Sample data for group composition bottlenecks..................................................25 Table 8: Sample data for group dynamics bottlenecks ......................................................26 Table 9: Sample data for availability bottlenecks..............................................................28 Table 10: Sample data for bottlenecks related to access to artifacts and tools ..................30 Table 11: Sample data related to meeting management bottlenecks .................................32 Table 12: Sample data related to functionality bottlenecks ...............................................34 Table 13: Sample data related with usability bottlenecks..................................................37 Table 14: Sample data related to technology availability bottlenecks...............................38 Table 15: Sample data related to drawing content bottlenecks..........................................41 Table 16: Sample data related with symbols section .........................................................43 Table 17: Sample data related with drawing visualization bottlenecks.............................45 Table 18: Sample data related to remote pointing bottlenecks ..........................................47 Table 19: Sample data related to annotation bottlenecks...................................................49 Table 20: Sample data related with navigation bottlenecks...............................................51 Table 21: Sample data related to visibility bottlenecks .....................................................54 Table 22: Sample data related with manipulation bottlenecks ..........................................57    vi Table 23: Sample data related with information exchange bottlenecks ............................59 Table 24: Sample data related with information interdependency bottlenecks .................61 Table 25: Sample data related with information availability bottlenecks..........................62 Table 26: Sample data related with analyses bottlenecks..................................................64 Table 27: Sample data related with ambiguity bottlenecks ...............................................65 Table 28: EEEL project bottlenecks table .........................................................................69 Table 29: CIRS Project bottlenecks table ..........................................................................70 Table 30: Framework table with referenced work.............................................................77                        vii LIST OF FIGURES Figure 1: 3D renderings of the Centre for Interactive research on Sustainability (CIRS) Project ...................................................................................................................7 Figure 2: Paper based meeting setting, digital meeting with Smartboard use ...................10 Figure 3: Layout of the third floor meeting room in architects’ office building ...............11 Figure 4: Different representations of the project information displayed on the wall.......12 Figure 5: 3D renderings of the EEEL Centre Project ........................................................13 Figure 6: (a) Distributed meeting with shared desktop and Smartboard use. (b) Paper based, co-located meeting. (c) Distributed meeting with the phone connection, no video connection between distributed teams .................................................14 Figure 7: Different drawings are often used at the same time while performing a meeting task ......................................................................................................................39 Figure 8: The list of drawings in Revit software helps the users to move easily in between different drawings ...............................................................................................50     viii ACKNOWLEDGEMENTS I wish to express my gratitude to my research professor, Professor Sheryl Staub- French and my co-supervisor, Professor Melanie Tory for their support, encouragement, and valuable suggestions through out this research. I would also like to express my gratitude to my parents in Turkiye, who have always supported me through out each and every step of the way. I thank them for their unconditional love and their trust.   1 CHAPTER 1: INTRODUCTION During the design phases of a project, building design teams meet regularly to control and monitor the design process, to share design information, and to coordinate the various discipline’s designs. The system designs are iteratively updated to accommodate each discipline’s requirements.  Successful management of this design process is critical to the efficient delivery of cost-effective and quality projects (Chua et al. 2003).  The decisions made during building design involve and affect many stakeholders, including architects, engineering consultants, construction managers, facility maintenance organizations, facility users, and property managers. Coordination among stakeholders, therefore, is critical to ensure that the design meets the functional, aesthetic, and economic requirements of the owner. Digital technology has become integral to the design process with much of the design work being done on computers. Design coordination in these multidisciplinary meetings, however, is still largely accomplished using paper printouts of 2D schematic diagrams and related project information. In recent years, there has been a growing interest by building design teams to leverage digital representations of design information during these meetings, particularly as more teams adopt a 3D design process. A 3D design process encourages the transition to digital meeting spaces because 3D design information cannot be easily printed. However, it is still unclear how to best integrate digital representations into existing meeting practice. The goal of this study is to better understand the challenges faced by project teams as they coordinate designs in multi-disciplinary meeting environments.  I focus on the bottlenecks encountered during in-person and distributed project coordination   2 meetings. I observed meeting bottlenecks when meeting activities were performed inefficiently, when the meeting process was slowed down, when meeting workflow was interrupted, or when decision-making was hindered.  I identified and characterized meeting bottlenecks observed in over 40 design coordination meetings during the design of two building projects in Vancouver, British Columbia.  I classified these bottlenecks in a framework that illustrates the nature of the bottleneck, and the frequency of its occurrence in design coordination meetings.  Some of the shortcomings of the meeting settings, technologies, and interaction methods used during the observed meetings are emphasized in this study. My hope is that these findings will inform the design of new interaction and visualization technologies that better support the meeting processes of design teams. I believe that most of the bottlenecks observed in the design coordination meetings can be mitigated by adopting existing or new technologies, which could have a significant impact on the efficiency of the design teams in coordination meetings. 1.1  Summary of Research Method In this research, observations from 40 design coordination meetings from two different projects are summarized. Most of the meetings attended (28 out of 40 meetings) were traditional paper-based co-located meetings where all the meeting participants were in the same room and there were no available meeting support tools or technologies. In addition to the 28 traditional meetings, eight distributed meetings, two digital meetings, and two meetings with limited Smartboard use were observed. All meetings were video- taped for future analysis. These observations occurred over a period of sixteen months which allowed the observation of design meetings from the conceptual design phase to detailed design and up through the completion of the construction drawing sets.   3  Meeting observations were focused on the meeting practices of the design teams. I observed how the participants performed meeting activities including common interactions with the information artifacts, social and cultural interactions between participants, factors that affected the workflow and information sharing, and how different technologies were used to share information and coordinate the design. I took detailed notes during the meetings to document the parts of the meetings where the participants could have performed tasks more efficiently. These notes also included data about the kinds of information exchanged and required during the coordination meetings. The causes for inefficient meeting practices were later analyzed. I concluded that there were specific meeting bottlenecks caused by the characteristics of different meeting components. Here the meeting components are defined as the combination of meeting space, design team, meeting processes, meeting artifacts and meeting technology that form a meeting setting. These different components of the meetings are called the “context” or “intervening conditions” in grounded theory (Borgatti, Steve). Based on my notes and subsequent video analysis of the meetings, I developed a framework to characterize the different bottlenecks observed.  The framework represents both context and content-based factors that caused the different bottlenecks.  I plotted the bottlenecks observed in each meeting within this framework to get a sense for the frequency and importance of the different bottlenecks.  Next, I performed an extensive literature review and identified research that focused on similar topics. The literature showed that there were overlaps and similarities between the bottlenecks I observed with those observed and analyzed by others. In the final step of this study, I mapped this   4 related literature to the framework to get a sense for the kinds of bottlenecks that have been identified by others. 1.2 Summary of Results There are basically three outcomes or results from this research: (1) Detailed observational data of design coordination meetings, (2) A framework that characterizes the bottlenecks observed in design coordination meetings, and (3) An analysis of the work practice of project teams in design coordination meetings, particularly in terms of the challenges of providing technological support for the early phases of design. The observational data includes detailed notes and photos that capture relevant information about the design coordination meetings observed.  These notes summarize the meeting context, relevant points about the nature of the meeting discussion, and any and all bottlenecks observed.  The meeting context is described in terms of the people involved, the meeting space, and the technology used.  The nature of the observed bottlenecks were noted and used to develop general categories for characterizing the bottlenecks. Based on the observational data and analysis of other research, I developed a framework that characterizes the bottlenecks in design coordination meetings. According to my observations, there were two main categories of causes for the bottlenecks in the meetings. I name these two categories context-based bottlenecks and content-based bottlenecks. Context-based bottlenecks are caused by the people in the design team, the meeting environment and the meeting technology. Content-based bottlenecks are related to the nature of the information artifacts (e.g., drawings and other design information) and the interactions with these artifacts. Content-based bottlenecks relate to   5 representation of design drawings (e.g., symbols and visual representation), interactions and access to information artifacts (e.g., navigation and annotation), and dependencies on information (e.g., analysis and  exchange). Design coordination meetings have special characteristics that make the meeting process challenging. Discussion topics are interrelated and there is a great amount of information created and referenced during the design process. Team members are dependent on the knowledge and the work of others’ to carry out their designs. This dependency on people and information makes collaboration between participants crucial for the success of a project. There is a need for better access to information, better means of information visualization, and better means of interaction with the information to make information exchange and communication more efficient during the meetings. We have found that time is a critical consideration.  New tools or methods developed to support this process should not interfere with the workflow of the meeting and should provide seamless information exchange amongst participants. My hope is that by better understanding the meeting process, we can design technologies that provide better support for the unique needs of building design teams.  In particular, technologies that enable better interaction with information artifacts, seamless exchange of data in meeting settings, and advanced visualization technologies for better communication and decision- making. 1.3  Outline of Thesis This thesis consists of six chapters. Chapter 2 provides background information about the two different projects that are the subjects of this observational study. Information about the project characteristics and meeting room settings are included in this chapter. Chapter   6 3   presents the step by step methodology of the research. In Chapter 4, the proposed meeting bottlenecks framework is presented, along with the representations of the observational data. Chapter 5 provides a literature review on bottlenecks in collaborative meeting environments. This chapter also includes a review of the work in digital meting environments. Chapter 6 presents the conclusions of the study of design meetings and meeting bottlenecks.  It also includes recommendations for future research focused on providing meeting support tools that improve the efficiency of project teams in design meetings.            7 CHAPTER 2: BACKGROUND ON STUDIED PROJECTS This research analyses the findings from a sixteen month field study of design development and coordination meetings for the Centre for Interactive Research and Sustainability (CIRS) and Energy Environment Experiential Learning (E.E.EL.) projects. In this chapter, information on the two projects, the coordination meetings and meeting spaces are provided. 2.1 Information on Centre for Interactive Research and Sustainability (CIRS) The Centre for Interactive Research and Sustainability (CIRS) will be located on the campus of the University of British Columbia (UBC). The research facility aspires to be the most innovative and high performance building in North America with a concept that emphasizes sustainability and collaborative research by many different bodies (Busby Perkins + Will, CIRS Project directory on Buzzsaw, Document: Design Rationale_ 22 August 08). CIRS is going to be a research centre for sustainable design, products, systems and decision making. The building itself has been a research project since the beginning of the design process by implementing the collaborative and innovative works of different teams in the process, in order to come up with the most sustainable solutions by studying the most advanced technologies to date.  Figure 1: 3D renderings of the Centre for Interactive research on Sustainability (CIRS) Project (Source: Busby Perkins + Will, on CIRS project directory on Buzzsaw)   8 2.1.1 CIRS Project Details The building is designed as a wood frame structure since wood is known as a sustainable material that is highly available in British Columbia. Salvaged wood from the existing building on site is also planned to be reused in construction of some parts of the CIRS building. While the CIRS facility is a UBC building, it is designed to promote collaboration with other regional academic institutions, including Simon Fraser University (SFU), Emily Carr Institute of Art + Design (ECIAD), and the British Columbia Institute of Technology (BCIT). Partners from private, public and NGO sectors will share the research facility. They will be working with the dedicated CIRS researchers on sustainable technologies, implementing these on the ground and help in using these technologies to improve British Columbia’s export market. The proposed gross floor area for CIRS is 4,607 sm. (49,571 sf.). The structure has the following components: a pair of 4-storey Office/Lab blocks running east-west, linked by an Atrium which acts as a building lobby and entry to a 500-seat Lecture Theatre for general campus use (Busby Perkins + Will, CIRS Project directory on Buzzsaw. Document: Design Rationale_ UBC Preliminary Advisory Urban Design Panel_ August 2008) CIRS is intended to be a state-of-the-art ‘living laboratory’ where researchers and building industry partners can perform research and assessment activities on current and future high performance building systems and technologies (CIRS Project, UBC website: The goal of the project was to design a highly sustainable building and adopt the sustainable design principles from the earliest phases. The building design and construction was funded by grants from the public and   9 private sector. Collaboration of different partners, consultants and researches had always been a project goal from the start. However some of the end users of the facility were not clear throughout the design process. The building is going to be occupied by researchers from academic partners of CIRS, who work on different parts of the sustainability domain. Because of this specific characteristic of the project, the design process was a little different because without a solid building program and defined set of users, designers faced more ambiguities than they would in a traditional project. For example, instead of designing specific office spaces, the office wings on each side were designed mostly as open space. The project was being designed with flexibility in mind, in order to allow for possible future changes in users’ needs. This lack of clarity of the building program made it a more challenging design process.  For example, it was difficult to determine the required mechanical loads for some parts of the project since the consultants did not know if the office spaces would be equipped with machines that needed extra cooling or special wiring. Our research group has been involved in the CIRS project throughout the design of the first CIRS building, which was later moved to the UBC campus. Eventually the building had to be redesigned according to the constraints of the new site and the budget once it was decided to be built at UBC. The design team was dedicated to moving to a paperless design process as a part of their sustainability design goals. Building information modeling (BIM), a practice and technology to help design teams work collaboratively, was accepted to be used during the design.  Dedication to BIM use and commitment to collaborative work and early involvement of the stake-holders in the design process made this project an interesting case to study meeting bottlenecks.   10 2.1.2 CIRS Coordination Meetings and Meeting Spaces The CIRS project coordination meetings were held at Busby Perkins + Will (BPW) (project architects) downtown office. Over a period of sixteen months, 29 coordination meetings from various project phases were observed and video-recorded for future analysis. The meetings were mostly paper-based and co-located; however there were some meetings where the design team took advantage of a meeting room with a touch sensitive Smartboard system with two displays (Figure 2 and Figure 3).  Figure 2: Paper based meeting setting (left), digital meeting with Smartboard use (right). The number of group members in the meetings was up to twelve people at times. The number of people in the meetings changed from week to week, but this number can give a general idea about the size of the observed meeting group. During the later phases of the design, the average number of meeting participants was five. The project team used Autodesk Buzzsaw to store and share project information, which included updated design drawings and documents from different consultants, reports, drawing sets that were submitted for the permits, and other project related documents were posted on this site. Three different spaces within the BPW office building have been used for the meetings depending on space availability and the need for Smartboard use during the meetings. The digitally supported meetings that required the use of the Smartboards were held in the third floor meeting room where the system was installed (Figure 3). This   11 meeting room had a Smartboard whiteboard system with two touch screen displays, a TV equipped with a camera, a receiver and speakers for net meetings, a telephone line and internet and power outlets (for laptops) were built into the meeting table. Smartboard displays were hooked to a computer in the room, but this computer was not connected to the office network. During the digital meetings one of the meeting participants opened the required files and facilitated the navigation on the computer screen with a keyboard and a mouse that were connected to the computer via Bluetooth. On one wall of the meeting room, there were two roll down curtains to be used as projection screens. On the same wall there was a board to pin different drawings during the meeting. The third floor meeting room was also the place where confidential meetings were held, since the room was designed to be sound proof.  Figure 3: Layout of the third floor meeting room in architects’ office building (The second floor meeting room had the same layout but did not have the interactive whiteboard system). The second floor meeting room was designed to support paper-based meetings. There were also a telephone and an additional table in the room. On one wall, there was a white drawing board. Paper drawings were sometimes attached to and displayed on this board by using magnets (Figure 4). The additional table was usually used for storing different drawings or as a place to display the big scale physical model. Both meeting   12 rooms were of the same size and were furnished with the same type and size meeting table and chairs. Only one of the meetings was held in the main floor meeting area which had a more open room setting.  Figure 4: Different representations of the project information displayed on the wall. Table 1: Breakdown of the observed CIRS meetings Paper Based Meeting Co-located 26 Digital Meeting with Smartboard use Co-located 1 Paper Based Meeting with Smartboard use Co-located 2  2.2 Information on Energy Environment Experiential Learning (E.E.EL.) Centre (in University of Calgary): The Energy Environment Experiential Learning (EEEL) building project is located on the University of Calgary campus and is currently under construction. The EEEL building will provide over 10,000 square meters of multi-disciplinary space for undergraduate laboratories, classrooms and seminar rooms, group and individual study spaces and research laboratories. EEEL will host new and existing collaborative activities for many departments, as well as the Institute for Sustainable Energy Environment and Economy (ISEEE), the School of Public Policy and other associated research space (<>, accessed on September 3, 2009).  The building program for the EEEL project is shown in Table 2.   13  Figure 5: 3D renderings of the EEEL Centre Project (pictures are courtesy of Cohos Evamy and Busby Perkins + Will, source: < FINAL-DD_web.pdf>)  2.2.1 EEEL Project Details Project Owner:  University of Calgary Architect:   Cohos Evamy, Busby Perkins& Will Structural Engineers:  Read Jones Christoffersen, Cohos Evamy Location:   Calgary, Alberta Table 2: EEEL Centre Program (<> accessed on September 3, 2009) Space Type  Units  Total NASM Ave NSM/Unit Comments Laboratories  34  4020  120 All types: wet, dry, computer, research & teaching. Classrooms  10  780  82 Standard T&C, basic infrastructure, flexible seating Support  36  1231  34  Includes activity & building support, sizes vary Offices (head count)  291  1847  6  # = head count, incl. faculty, staff, grads Seminar/Study  29  530  18  Project & break-out, home rooms, sizes vary Theatres  3  873  291 Equipped for demonstrations but not restricted to E+E Public/Retail  3  720  240  Foyer allowance, social, interaction, display, link Total  405  10000    14 2.2.2 EEEL Coordination Meetings I observed and recorded eleven coordination meetings of the EEEL Centre project, from conceptual design through detail design phases. The architectural design of the EEEL project was the collaborative product of two offices; Busby Perkins + Will, whose main office is in Vancouver and Cohos Evamy from Calgary. Most meetings were held in Cohos Evamy Calgary office, and architects from Busby Perkins + Will Vancouver office joined the meetings over the phone. Sometimes an architect from the Vancouver office attended the meetings in Calgary in person, while his coworkers joined the meeting over the phone from Vancouver. The EEEL project was chosen as a part of my observational study because it allowed me to study the coordination meetings of a team in both co-located and distributed settings.  Figure 6 shows the different meeting environments used during the EEEL project.  (a)    (b)    (c) Figure 6: (a) Distributed meeting with shared desktop and Smartboard use. (b) Paper based, co-located meeting. (c) Distributed meeting with the phone connection, no video connection between distributed teams.  Table 3 shows the breakdown of the different meeting types.  Most of the observed EEEL meetings were teleconference meetings with only audio connection. Distributed meetings, where the participants in the Calgary and Vancouver offices had only a telephone connection, were observed to analyze the bottlenecks that were caused because of not having a visual connection of any sort between distributed meeting   15 groups. There were also several paper based meetings held in the Vancouver office between the architects from Cohos Evamy and Busby Perkins + Will. The structural and mechanical consultants joined these meetings over the phone from their Calgary offices whenever their input was needed. One of the observed EEEL meetings was a distributed, teleconference meeting with Smartboard use, where each office had visual access to other’s computer screen, by the help of software that allowed desktop sharing. During this meeting, participants were able to make instant annotations on screens and discuss various alternatives by using the Smartboard technology (Figure 6a). They were able to make annotations, marking, pointing etc on the displayed drawings. EEEL meetings were held in the third floor meeting room in the BPW office (this meeting room was described in section 2.1.2). Table 3: Breakdown of the observed EEEL meetings Paper Based Meeting Co-located 2 Digital Meeting with Smartboard use Distributed 1 Conference Call (over the phone, w/o video connection) Distributed 8                16 CHAPTER 3: METHODOLOGY The overall objective of this research was to identify and characterize meeting bottlenecks in building design coordination meetings.  I conducted this research by performing an ethnographic study where I primarily focused on collecting and analyzing observational data from various design coordination meetings. Instead of observing many different meetings from different phases of projects, I focused on pre-construction design coordination meetings. Forty consultants’ coordination meetings of two different projects were attended in the architects’ office during the study. Both of these projects were educational research buildings. My approach to this research was inspired by grounded theory (Borgatti, Steve). I studied the work practice of project teams in the field and systematically collected and analyzed qualitative observational data in the form of textual descriptions of the meeting process. My observations, combined with the background research, helped to formulate the intuitions about the bottlenecks in the design coordination meetings.  Table 4 summarizes the specific research tasks that I carried out, which will be described in detail in the remainder of this section. Table 4: Summary of research tasks Understand the meeting processes of the observed design teams  1. Literature review 2. Observe and document meetings 3. Interview meeting participants 4. Prepare meeting summary documents 5. Video analysis 6. Analyze meeting bottlenecks 7. Create framework to characterize the meeting bottlenecks 8. Map meeting bottlenecks into the framework 9. Map framework with references      17 1. Literature Review Although this step was initiated before the start of the observational study, it continued throughout the preparation of this thesis. During this step, I gained an understanding of previous research that focused on meeting activities, use of artifacts in meetings, collaborative working environments, meeting bottlenecks, etc. An extensive literature review also allowed me to put together a table of bottlenecks that were observed and analyzed by other researchers. My intention for preparing this kind of a bottlenecks table was to base my initial framework on the literature review and to list the different types of bottlenecks (if any) that I might observe during my analysis. My initial bottleneck breakdowns were inspired by the previous studies combined with additional bottleneck groups based on my intuition. 2. Observe and Document Meetings I observed forty design coordination meetings over a period of sixteen months. The meetings were of different formats and settings. Thirty of the observed meetings were co- located, paper based meetings where the participants were in one room; using physical artifacts like paper drawings, project model, reports, artist’s renderings etc. Nine of the observed distributed meetings were EEEL project meetings. I also observed two digital meetings during which the Smartboard interactive display system was used. Table 5 shows the breakdown of the observed meetings and meeting types.      18 Table 5: Breakdown of the meetings observed   CIRS EEEL   Co-located Distributed Co-located Distributed Paper Based 26  - 2 - Digital (with Smartboard use) 1  -  - 1 Paper Based (with Smartboard use) 2  -  -  - Conference Call (Over the phone w/o video)  -  -  - 8  During the observational study, I looked for inefficient meeting practices, situations where the meeting workflow was interrupted or situations where I thought that the meetings tasks could have been performed easier if meeting technologies were available. If there was a meeting technology available in the meetings, I evaluated the appropriateness of it during the execution of the meeting tasks. I also observed the team members’ interactions with the information artifacts in order to better understand the use of these artifacts during the meetings. I also considered the interactions between meeting participants their effect on the overall meeting process. Observed interactions were noted with the actual time and descriptions by the observer in order to reflect the context during the meeting. I tried to document each meeting according to all the above mentioned perspectives. These perspectives were formed by the findings from the background research and my intuition about the meeting bottlenecks. The meetings were captured on video for further analysis and meeting notes about the meeting events were taken throughout the meetings. The meeting recordings were also used to get snapshots from the meeting. Advantages of using video recording are also explained by Jordan and Henderson (1993). Video can also be watched again later   19 and coded in detail, unlike live observation. I also documented the artifacts by taking pictures, whenever the design team used a large number of artifacts during a meeting. 3. Interview Meeting Participants Short interviews with the meeting participants were occasionally performed to learn about their experiences with the use of Revit in collaborative design and also to evaluate their meeting practices. These short informal talks helped to better understand why the design team was sometimes limited to the meeting technology that was available. For instance, the reason why the EEEL meetings were often held through only a phone connection was the unavailability of the meeting room in the Calgary office where collaborative meeting technologies were available. An interesting comment was made by an architect in the Vancouver office, about the network between Calgary and Vancouver offices which was used instantaneously by designers from both offices during the creation of the Revit model. This architect named the network itself as one of the biggest bottlenecks in the design process. He explained how sometimes people forgot to sign off after working on a part of the design and the network did not let other people work on the specific part before the first designer signed off. During such times, the designer would work on another section of the project or wait for the other user to sign off. 4. Prepare Meeting Summary Documents After each meeting, I prepared a meeting summary document according to the meeting notes as soon as possible while the memory about the meeting was still fresh. This method allowed me to explicate my meeting notes. The meeting documents contained detailed observations and analysis of each meeting. Instances of intuitively identified bottlenecks, examples of the bottlenecks that were identified by previous   20 research, information about the discussion topics and meeting activities were included in the meeting documents. Meeting participants, meeting agenda (if available), available artifacts, important snapshots of the meeting with context descriptions, analysis of certain observed events were documented as well.  Although the meeting documents were prepared at the same time as the background research, this activity was not limited to the extent of the previous research. The observed bottlenecks were listed freely whether they belonged to any specific predetermined framework or not. 5. Video Analysis Seven of the meetings were extensively coded by using the video recordings, in order to get more detailed data and to look for the meeting bottlenecks that might have been missed during the actual meeting observation. These seven meetings did not have any special characteristics than the rest of the meetings.  Meeting documents with different detail levels helped to compare “during meeting” and “after meeting” observations. In a detailed video analysis document of a meeting, I was able to observe the durations for each discussion topic or see the shifting of discussion topics more clearly. However my intention during these meeting analyses was to capture the bottlenecks related with the artifact use, information flow, technology, decision making etc. The main goal of the study wasn’t creating the minute by minute coding of the meetings. So I decided that I didn’t need to prepare extensive video-coded meeting documents where I would document every minute of each of all of the forty meetings. I continued to form my meeting documents from the notes I took during the actual meetings. Snapshots from the meeting videos were also used along with the meeting notes in order to give a visual reference to the reader about the specific moment and the   21 meeting setting. The large number of meetings that were observed helped to put together a set of data to work with, even though an intensive coding method for each meeting video was not chosen. 6. Analyze Meeting Bottlenecks After completing the documents of all forty meetings, I performed “open coding” (Borgatti, Steve) of this data set from the meeting documents. Using this approach, I derived a list of bottlenecks that were observed in each meeting. Each bottleneck in this document was named intuitively but still in relation with the earlier background readings. A brief description, a vignette, of the observed event was also added to the list. The vignettes include context information (sometimes with a snapshot from the meeting) and provide intuitive clues for the reader about the specific bottleneck. In doing so I not only provided textual descriptions of a particular situation but also created a visual and mental reference (with snapshots) for the reader to better understand the specific meeting setting, and meeting environment (which may have a direct influence on the existence of a bottleneck) in order to better characterize the bottleneck. After the open-coding, I searched for general patterns between kinds of bottlenecks in the meeting documents and then defined and grouped the causes of the bottlenecks, which will be explained in more detail in the next step. 7. Create a Framework to Characterize the Meeting Bottlenecks After defining the bottlenecks in the previous step, I searched for the reoccurring bottlenecks in order to put together a framework for characterizing these bottlenecks. Looking at the meeting bottlenecks documents I grouped similar kinds of bottlenecks under different topics. The topics included the bottlenecks which were observed and   22 named intuitively, but were not a part of the literature review. An “axial coding” (Borgatti, Steve) of the data was performed by iteratively refining the categories in the framework by using the available data. Naming the bottlenecks was based on both the information that was collected from the background readings and the intuitions based on observations. When naming the bottlenecks, I sometimes used different wordings or the same wording as a reference, but in a different meaning. After this iterative process, I finalized the framework to be used in characterizing the information embedded in the meeting files. 8. Map Observed Meeting Bottlenecks into the Framework Mapping observed bottlenecks into the created framework helped to evaluate the completeness and suitability of the framework content. This step had an overlap with the previous step. The iterative process required crosschecking the adequateness of the topics in the framework with the frequency of occurrence of bottlenecks. If a topic didn’t have enough or no examples in the observations, that topic was deleted. Some topics were divided into more different topics if I decided that I couldn’t communicate the differences under the same topic. I tried to make sure that the framework was detailed enough to accommodate the bottlenecks that were defined during the analysis. 9. Map Framework with the References In this step I referenced parts of my framework that were influenced by the background readings and research. To visualize this, a separate table of the framework was prepared where I mapped the different references with the topics in the framework. This step also helped to summarize the previous research work on the framework topics.    23 CHAPTER 4: CHARACTERISATION OF DESIGN MEETING BOTTLENECKS In this chapter I present the framework proposed for characterizing the meeting bottlenecks in design coordination meetings (Table 6). This chapter contains detailed information about the framework including the specific representative bottlenecks identified during the observational study. Each bottleneck group is described further with the sample data from the actual meeting observations (vignettes). These vignettes include contextual information about parts of a meeting to help the reader to evaluate the context of the bottleneck. Based on my observations and background research, I characterize bottlenecks in three categories: context-based bottlenecks, content-based bottlenecks and project- specific bottlenecks. In this section, these three main bottleneck groups will be summarized and subgroups of the bottleneck groups will be explained in detail. Table 6: Framework of the categorized meeting bottlenecks.    24 4.1 Context Based Bottlenecks This section will define the bottlenecks caused by the overall meeting setting. Context-based bottlenecks are the results of meeting characteristics and are listed under three main categories: people, meeting environment and technology. 4.1.1 People Collaborative work involves groups of people working together towards the same goal. In the construction industry, the design teams are usually from different companies and from different professions. These people usually work together for the duration of a project. Effective collaboration is therefore essential for the success of the project.  My framework further breaks down bottlenecks that result from ‘people’ based on group composition, group dynamics, and availability. Group Composition: The composition of a design team may change multiple times as the team players sometimes change throughout the project phases (Liston et al. 2001).  A change in the group composition is not itself always a bottleneck but it may be the cause for a bottleneck. When a team member changes, his/ her knowledge about the evolution of the design may not be completely transferred to his/ her successor. This creates gaps in information flow between team members and may cause bottlenecks during later phases of the design. Frequent changes in the group composition can also affect the cohesiveness of the group. The meeting participants are from various professional backgrounds. While each participant has a wide knowledge about a domain, he/ she might have little or no knowledge about other domains. This issue creates a need for often describing domain specific design criteria amongst participants, which sometimes takes a great part of the   25 meeting. The people in the meetings have different levels of experience. Level of experience is observed (in our ethnographic studies) to have an influence on how people look at a certain problem or an issue, and it also has an effect on the information flow between the participants. Table 7 describes a few bottlenecks that I observed in the meetings that result from group composition. Table 7: Sample data for group composition bottlenecks Each time a team member changes it takes time to get the new member fully on board, the project information might not be completely transferred from the previous team member to the next. Change in the team composition: new electrical consultant takes over the project and joins the project team. During the meeting architect wants to learn the electrical consultant's plan for relocation of some power lines. The new consultant does not have that information yet. The architect says that if there was a plan, the previous consultant should have updated  the new member about that plan. (CIRS_ September 24, 2008). Architect asks for an update about a part of the mechanical system which was discussed some time ago. Mechanical consultant apologizes for not having that information. Architect says “it is okay, you joined the team later during the design process, and we discussed this before you joined the team” This example shows the breakdown in the information flow as a result of a change in the group composition.(CIRS_ March 11, 2009)  Group Dynamics: This section covers the bottlenecks that occur because of the personal interactions between the meeting participants and behavioral characteristics of the group members. The people in the meetings have different characteristics, responsibilities and authority. These factors influence the interactions between the meeting participants. It is important for the project team to be able to work in harmony. The way people interact with each other in a group is observed to have an influence on the meeting processes in this study. The character or personality of an individual might have positive or negative effects on the meeting process (e.g., works well in a group, gets required information on time, is dominant in a meeting, tries to over-control everything and complains about others’ progress, etc). During the CIRS meetings, I observed the architects sometimes   26 having problems finalizing their design on some parts of the building because of the slow progress on the mechanical design. During the meetings, I observed that the architect mentioned several times that the mechanical design was not progressing according to his expectations. There were instances where both sides challenged each other, trying to point out the missing or poorly detailed components in each others’ drawings. Such observations are documented as a group dynamic that influenced the efficiency of the collaborative design work and resulted in meeting bottlenecks.  Table 8 describes several bottlenecks observed that resulted from group dynamics. Table 8: Sample data for group dynamics bottlenecks Architect is not satisfied with the progress of the mechanical design, and he doesn't hesitate to express it during the meetings. Architect to mechanical consultant: "You have seen the mechanical room in the basement. Up until now what was your plan (regarding equipment access issues)? Cursing architects?".  (CIRS_ July 30, 2008) Architect to the owner's representative: “I would like them (mechanical consultants) to optimize their design in a way that makes more sense…” (CIRS_ March 04, 2009) Domination by one of the team members may cause apprehension for expression of ideas by other group members. After the architectural office's partner leaves the meeting room the consultants become more relaxed and move their chairs to a more comfortable position.  However, I can not for sure say that domination was the only cause for the fewer or no comments made during the presence of the office's partner. (EEEL_ April 17_ 2008) According to my previous observations I believe that the architect feels like he is already performing more tasks then he is supposed to. So he is not willing to volunteer for a new responsibility. A decision has to be made and an action needs to be taken. Architect: “we need to find a champion and we hope that is not me”. Owner's representative says that he is going to be the champion. (CIRS_ September 17, 2008) Architect: “I am just trying to push responsibility to M (plumbing consultant)” (CIRS_ April 08, 2009) Team members have different goals about the design process and BIM. Some of the consultants are more concerned about time. Architect mentions resynchronization of drawings. Owner's rep. wants to know why they need the project models at the first place. Later in the meeting he expresses his concerns about starting with Revit and about possible architectural design changes. Owner's representative: "Should we coordinate at own offices? It is going to be a big loss of time if everybody … What we will be looking at on the model during the meeting?". (CIRS_ September 10, 2008) Even though the Revit and BIM use was a project goal at the beginning; complete dedication to BIM by the team wasn’t observed throughout the observations. The groups' ideals about the new technologies were influenced by the group dynamics along the way. Electrical consultant mentions schedule constraint versus Revit use: "if the schedule does not let Revit use, our priority would be getting the project done". (CIRS_ September 10, 2008)    27 Availability: Sometimes people with the required information or knowledge were simply not present in the meetings to make the necessary input on a discussion topic. There were two common reasons for this bottleneck subgroup: (1) a team member who is a part of the regular meeting group was not available in a meeting or during a part of the meeting, and (2) a person with the required knowledge and authority on a discussed topic is required in a meeting. The availability bottleneck caused delay in making decisions or a delay in getting the information that was needed by a consultant. The meeting group should include the people that are needed to make an informed decision on discussed issues. People who are the final decision makers on an issue, or who hold a specialized knowledge about a part of the design should also be invited to meetings when needed, in order to avoid extended decision making times. The design of the CIRS project included systems that were supplied by a number of technology partners. There were times when the consultants needed more detail or clarification about these systems, but since the technology partners weren’t regular meeting participants, the consultants’ questions remained unanswered during the meeting.  Table 9 describes several of the bottlenecks observed related to the availability of people or knowledge.   28 Table 9: Sample data for availability bottlenecks Before the meeting architect thought that owner's representative did not have to join the meeting, and told him that it was okay if he did not come to the meeting. But it turns out that he was needed for the clarification about UBC’s policy about the soil anchors. The issue remained unresolved during the meeting and the participants decided to get the required information from the owner after the meeting (CIRS_ April 01, 2009) The building is going to be built in phases and the participants are not sure when auditorium is planned to be built. Mechanical consultant has a concern that ground source cooling system construction (which will be underneath the auditorium space) would lengthen the construction time but architect doesn’t think so because he believes that auditorium will be built at the end. CM representative is not present during the meeting to clarify the sequencing of the construction. If CM was in the meeting he could give more information to resolve this issue.(CIRS_ March 25, 2009) During the design technology partners supplied the architects with drawings of different systems and system components, which were later incorporated into the architectural design.  The design team has questions about the proposed systems but the technology partners are not a part of regular meeting group. Consultant asks architect why these people are not coming to the meetings to share their insights about the systems that they propose.  (CIRS_ February 18, 1009_ 7' 13"of video recording) When a topic about a previous meeting was being discussed the mechanical consultant could not help with the issue because he was not present in that meeting, that’s why he was unaware of the previous discussion. (CIRS_ September 17, 2008) Solar hot water issue: electrical consultant is not present in this meeting so the architect says that they might have to talk about this issue again next week. I do not have information about whether this example caused any delays in the design process, but I believe the issue could have been discussed and maybe solved during this meeting (CIRS_ February 11, 2009)  4.1.2 Meeting Environment This section covers the bottlenecks related with the access to meeting artifacts & tools, and meeting management process. Access to Artifacts and Tools: Depending on the type of the meeting technology or artifacts used, having means of access to these tools and artifacts becomes important in the group setting. Especially in digitally supported meetings, display location, orientation, and interaction become critical since the group focus is on these displays. Orientation of the display, to be able to view the information on the displays, and having means of remote interaction become important for working efficiently in the meeting environment when the participants need to directly interact with the displays. Interaction bottlenecks will be discussed with the content-based bottlenecks.   29  Design teams use a large amount of project information during the coordination meetings. This information comes from different domains and teams may need to access this information during any meeting, at any moment. The discussion topics are interrelated with other parts of the design. Most of the time, it is difficult to know which information will be needed during a meeting. These characteristics of meetings make it hard to predict which documents will be needed during a meeting so that they can be prepared before the meeting. Access bottlenecks can result from many situations, including a meeting participant’s proximity to the telephone when there is a tele-conference meeting, or not having access to the remote interaction tools when using Smartboard technology in a digital meeting, or not having access to a physical model that is being used by a consultant during a design update. The meeting room layout can also trigger some bottlenecks if the meeting process is not supported with the right meeting tools. Form of the meeting space, furniture and the seating arrangement in the space also trigger some of the bottlenecks we observed in the meetings. Depending on the number of the participants, specific room layouts can create bottlenecks in interaction, viewing and access to information artifacts.  Table 10 describes some representative bottlenecks that were observed related to access to artifacts and tools.   30 Table 10: Sample data for bottlenecks related to access to artifacts and tools While the owner's representative is talking about an issue about the site and one of the neighboring streets, he does not use the physical model which sits on an additional table in the room, simply because he does not have a more efficient way to interact with the artifact other than standing up and getting closer to the model. (CIRS_ September 17, 2008) Architect sketches the area needed by the electrical consultant on the drawing according to consultant's input. Electrical consultant is sitting on the other side of the table and he verbally explains the space he needs for his systems. Sometimes the participants don't bother to even stand up in order to point to things, or sketch something on the board. This might be a sign that shows the need for tools for remote interaction with the artifacts which would improve the workflow. (CIRS_ July 30, 2008) Structural drawing set is being used during the structural design update. At the other end of the meeting table architect has to open up the architectural drawings when explaining something about the discussed issue to CM's representative. The architect and the CM's representative do not have access to the structural drawing from thier side of the table.  (CIRS_ February 11, 2009) Participants need to move the drawing around to take a better look at it. Participants talk about the design as they view the drawing. Not all participants have access to the drawing during the discussions.  It is hard for the participants to view and interact with the artifact  collaboratively at the same time (CIRS_ January 21, 2009) The Smartboard system is operational but instead of walking up to the screen to do his sketch, he prefers using paper that is in front of him which is more accessible. If there were remote interaction devices available in the meeting room, the architect would be able to easily sketch on the Smartboard, and all the participants would have a better view of his sketch. (CIRS_ November 05, 2008) The structural consultant does not have the glulam detail drawings with him. Drawing exists but it is not accessible from the meeting room. Architect stands up and sketches the detail on the board. If the participants were able to remotely access their files during the meeting it would be possible to use the consultant's drawing. Information that could easily be communicated through a drawing had to be explained with sketches and verbal descriptions. (CIRS_ February 25, 2009_ Picture from 28' 58" of the recorded video)  Meeting Management: Bottlenecks related with the way that meeting process is handled, including meeting facilitator’s preferred meeting management style, emphasis put on the meeting agenda and meeting minutes, inefficient use of meeting time as a   31 result of digression from the main topics, and forming the agenda from the issues that do not interest most people in the group. These observations are supported by the findings of Garcia et al. (2003) in their study on how to manage meeting agendas.  They found that a significant part of the agendas analyzed concern only a few people in the meeting group. I observed that some meeting facilitators put a great deal of emphasis on the agenda, while some prefer to work around a more informal and flexible format. However, I observed more digression and poor time management during the meetings where there wasn’t a well prepared meeting agenda available. I observed that meeting agenda and meeting minutes documents were more organized and formally prepared in the EEEL project when compared to the CIRS project meetings. During the meetings where there was a more formal and better prepared meeting agenda, digression was observed less, and discussions were focused on predetermined problem areas of the design. This helped the participants to better prepare for the meeting, since they knew the discussion topics before the meetings. There are various methods that meeting facilitators prefer to use for meeting management. Depending on the particular preferred meeting management style, dominance of a facilitator can be observed in some groups while there is a more comfortable collaborative environment in others. Domination of a participant during a meeting might also trigger apprehension. In the absence of the regular meeting facilitator I observed some bottlenecks related to lack of focus and digression. Table 11 describes several observed bottlenecks that were caused by meeting management.   32 Table 11: Sample data related to meeting management bottlenecks Architect describes a special detail about the “living wall” design to the structural consultant. He uses a smaller scale (A4 size) plan and he makes sketches on the same piece of paper. The detail is about the drip, splash issues about the living wall. It looks like this detail concerns only the structural consultant and could have been discussed privately with the consultant in order to use the meeting time more efficiently.  (CIRS_ February 18, 2009) Ground source heat pump: Owner's representative wants to see the cost of this system specifically. CM says that it would be better to let them know ahead of time about any price they need more information about. This could have been included in the meeting agenda but it wasn't done. Bottleneck might be the method used for creating the agenda. [21] contain detailed information on ways of creating and managing meeting agenda (CIRS_ February 11, 2009) The senior project architect, who is the meeting facilitator in CIRS coordination meetings, is not present in the meeting. There was shifting from the main focus of coordination and spending more time on details which often did not concern all participants. For example structural update triggered a discussion about designing a raised floor or a service space below the ceiling of an area. Architect and the structural  consultant sketched some ideas on the board. After some time, one of the consultants said that there is not going to be much service in that part of the floor assembly and  the design had not progreesed enough to discuss such details.  (CIRS  August 20, 2008)  4.1.3 Technology This section defines the bottlenecks observed related to technology functionality, usability, and availability. Functionality: Functionality bottlenecks were observed when a meeting technology was available, but a relevant function was not available. The technologies used in the observed meetings had advantages, but there were often shortcomings with their functionality for specific meeting purposes. Observations showed that sometimes the available meeting technology was not completely able to respond to the interaction needs of the participants with the information artifacts.  According to my observations, participants needed to be able to collaboratively use the available technology, particularly in digital meetings with the Smartboards. Multi-user interaction was one of the functions that the meeting participants did not have when they were using the Smartboards. The system did not allow multiple users to sketch at the same time, but the designers were tempted to add onto or manipulate each other’s   33 sketches instantaneously on the screen. The participants had to quit annotating on the screen in order to perform another task (e.g. opening a new drawing). Since there was only a keyboard and a mouse for remote interaction with the Smartboard, participants had to walk up to the boards each time they needed to interact with the displayed information. During the digital EEEL meeting (January 18, 2008), two distributed teams coordinated their conceptual design drawings over the shared desktop using the Smartboard screens. Each team was able to view the desktop of the other team but the system allowed only one team to manipulate the information displayed on the screen. One of the teams could only view the information and couldn’t perform actions like zoom, pan or rotate, which slowed down the process. These observations were noted as inefficient ways of performing some of the meeting tasks. Functional limitations of the technology interrupted the workflow and affected the efficiency of the group.  Table 12 describes several bottlenecks caused by the functional limitations of the collaboration technology used.   34 Table 12: Sample data related to functionality bottlenecks Two distributed design teams are having a digital coordination meeting by using shared desktop and Smartboard system. Calgary has the control of the shared visual representation on the screen. Vancouver office cannot manipulate the drawing and make it more readable. They have to tell Calgary office to zoom in on the current document. Vancouver: ”It’s a little illegible on our side. Can you zoom in on that”.   (EEEL_ January 18, 2008_ 2' 24" of recorded video) Time out: During his update architect realizes that there had been a connection problem. When they get connected again they find out that Calgary office did not hear his update about the design and Vancouver misses the section of the meeting during which they did not have connection. Architect asks the observer: “You recorded that right?” If there was also a video connection the team would have recognized the problem sooner. (EEEL_ June 12, 2008_  2' 12" – 4' 52") “If we go back to the first slide”. 1st architect stands up and grabs a Smartboard pen while 2nd one tries to move back to the first slide. 1st architect has to put the pen down in the tray so that 2nd architect can exit from the pen mode to the cursor mode, allowing him to go back to the respected slide. (EEEL_ January 18, 2008_ 35' 59" of recorded video) While looking at the Navisworks model on the Smartboard screen, architect mentions that he needs a layer control (like AutoCad) tool to be able to see the structural components behind the façade elements. (CIRS_ November 05, 2008) During the digital meetings with the Smartboards, there were times when two or more designers wanted to interact with the displayed information at the same time; to make annotations, to sketch a detail etc. However, Smartboard system does not allow multi-user interaction, so the participants had to take turns to perform each task.(CIRS_ November 05, 2008) Team goes online by using the Smartboard screens and goes to the manufacturer’s page to see the actual images of the fixtures. While discussing the electrical fixtures in the building, the model operator opens the related Revit drawing. Since Revit has limited object samples in its library, the lighting fixtures in the drawing do not represent the actual fixtures. (CIRS_ October 22, 2008)  Usability: This section covers the bottlenecks related to operating the available meeting technology. Usability bottlenecks are caused by the design of meeting technology combined with the lack of user experience. Digital meeting technologies are fairly new for many people in the industry. It takes time to learn the new meeting technologies since they have different uses than the digital tools that are commonly used by a designer   35 during his/ her everyday practice. Until the participants are familiar with the meeting technology, it takes longer to perform tasks, or they are sometimes perform inefficiently. The members of the design team can be from different age groups, with different experience with the current technologies. Some participants follow intuitions when interacting with a new technology and some try to use interaction techniques they learn from other technologies. Since there isn’t one standard way of interacting with the computers, it takes time and multiple errors to learn the new interaction methods. When we use the term interaction here, we refer to the Human Computer Interaction (HCI) domain, in relation to the use of knowledge of software or technology that is available in the meeting environment. If the meeting participants lack knowledge about the specific meeting technology, the frequency of bottlenecks occurring through interactions with the technology increases. When the meeting participants are not familiar with the available meeting technologies, they might not be able to use these technologies to their full extent. Or if the meeting group is unaware of the capabilities of the meeting tools, they might use these technologies in the most basic way or do not use them at all. During our studies, we often observed bottlenecks that were caused by a lack of experience with the technology. Designers did not keep snapshots of the annotated screen in order to be used later on. Teams did not use the Smartboards in the room, since they were not yet able to use the technology effectively. 3D model use and collaboration was also not accomplished effectively since the design team did not have the expertise to perform coordination tasks efficiently. Some consultants just did not want to spend time learning the new software and their excuse was the lack of time. They suggested that the speed of the evaluation of   36 the design and other time constraints were forcing them to make a choice between learning the latest technology, and getting the building done in time. Users’ experience level with the available technology also has a direct effect on the level of efficiency of using the meeting tools. I observed that one of the architects, who was using the 3D software for the first time, had problems navigating in the model because he wasn’t used to the navigation commands. The software’s command entry was designed for the use of a mouse, and sometimes required a left click and the movement of the mouse at the same time. But it was impossible to mimic such entry on the surface of the Smartboard screen. Another problem was using these commands on the Smartboard screen by entering them with his fingers. Some usability problems also resulted from poor technology design. For example, when the participants were using the Smartboards, they sometimes wanted to just point to objects on the screen but the system recognized each touch as a command and moved into the command mode. According to my observations, I believe that user interaction with the available meeting technology should be more intuitive. Interaction tools and methods should not be software specific so the users would not be forced into learning different methods each time they come across a new meeting technology. I would also like to quote a comment from one of my supervisors (Melanie Tory) here: “well designed technology should support users with limited experience.”  Table 13 describes several usability bottlenecks observed.   37 Table 13: Sample data related with usability bottlenecks Architect has to download the new structural drawing file on to the computer while other consultants are using the Smartboard to sketch and discuss a detail. When the architect moves his mouse to load the new file, the sketch on the screen, which the consultants were still discussing, suddenly disappears.  (CIRS_ November 05, 2009) Architect is pointing to the screen during his design update. Each time he accidently touches the screen, the system takes it as a command and performs an unintended action. Architect ‘with paper when you touch a plan it does not try to do something’. At one point he asks whether it is possible to turn off the touch function of the screens, so that people can use their fingers to point to objects on the screen without activating a command. (CIRS_ November 05, 2008) Architect is trying to navigate in the 3D model by entering commands on the touch screen. He gets disoriented in the model because he is not familiar with the navigation function of the software. He asks other consultant to get him back to the original view in the model. ‘Can you get us back to where we were?’ The software does not include an orientation window to indicate the users location in the model. (CIRS_ November 05, 2008) Structural consultant is trying to sketch on the screen by moving the pen above the screen surface, but nothing is coming up on the screen.  He is not familiar with the technology. Architect warns him ‘you have got to touch the screen (with the pen)’ (CIRS_ November 05, 2008) Vancouver and Calgary offices are having a distributed meeting (shared desktop, audio connection over the phone). Vancouver: “How do I control it (shared desktop). I have forgotten how to do this already from yesterday” (EEEL_ January 18, 2008_ 7'30" of recorded video) Designers in Calgary and Vancouver offices are having a distributed digital coordination meeting on Smartborads by using shared desktop. Architect stands up and tries to make dots on a diagram on the Smartboard screen. His Smartboard pen doesn’t work; first he thinks that Calgary has the control of the screen. Then he replaces the pen back and removes it again, this time pen works (interruption to the work flow)  (EEEL_ January 18, 2008_ 29' 57" of recorded video) Availability: Availability bottlenecks are caused by not having all the required support technology during the meetings. In some meetings, the available meeting technology may not support all the required interactions between participants and the tasks that need to be performed. Participants perform these tasks inefficiently because of the missing technology. Most of the bottlenecks in this section were observed during EEEL   38 coordination meetings where the only connection between two distributed groups of consultants was through a phone line. There was no visual connection between the people in different offices which made it hard to understand who was making a comment on the other side, it was impossible to see the artifact that the participants in Calgary were discussing, and it was hard to hear people who were sitting away from the telephone receiver. During the meetings, participants use gestures, body language or they need visual references to better understand what is going on in the meeting environment. Especially in distributed meetings, participants should be supported with visual tools that would help them observe the actions in the other meeting environment. This would also help them see the artifacts that are being used during the meeting. When there is no video connection between the distributed meeting groups there is no group focus, it gets harder to understand the discussions about the meeting artifacts, and there is no way of sharing design information.  Table 14 describes several examples of bottlenecks related to technology availability. Table 14: Sample data related to technology availability bottlenecks Vancouver and Calgary offices are having a distributed meeting (w/o video). Architect is imitating flipping the pages of a document or a drawing that is being heard through the phone. Vancouver team doesn’t know what artifact is being viewed in Calgary office. (The discussion is about an issue about the elevations of the tunnel) The sound of flipping through pages of a drawing continues and you can hear the meeting facilitator in Calgary saying that “looks like we have a coordination issue”. (EEEL_ June 12, 2008_ 32' 00" of the video) When the phone connection is established, the participants in Calgary are reviewing a landscape drawing overlaid on the site plan. Since the architect in Vancouver office has no visual connection to the meeting environment in Calgary office, he says: “it is a little vague” to express that he has no idea of what others are pointing at or discussing on the drawing. The architect in Vancouver office is trying to make sense of the conversations he hears on the phone because he can’t see the artifacts that are subject to the conversations. (EEEL_ July 24, 2008) Vancouver and Calgary offices are having a distributed meeting (shared desktop, audio connection over the phone line) Distributed meeting participants are unaware of what the other office see on their screens because they don’t have visual information about the other office.  Vancouver: “ok we see your drawing of the site plan” (1'18"). Calgary: ”Do you see that?”  Vancouver: “I see what looks like a little red spot” (2'01").   (EEEL_ January 18, 2008)    39 4.2 Content Based Bottlenecks Content-based bottlenecks are based on specific meeting content, including the use of available meeting artifacts, interaction with the artifacts, and the use of information. Content based bottlenecks are divided into three groups: drawings, interaction/access, and information related bottlenecks. 4.2.1 Drawings  Content: Each drawing is intended to communicate specific design information. Multiple artifacts may need to be used together in order to explain different characteristics of the design. Domain-specific drawings only focus on the information about a particular system design. Additional information about the components that might be needed by other consultants is not always detailed on these drawings. Content is limited to the intended use of a drawing. When different kinds of information need be viewed at the same time, participants end up using multiple drawings in order to communicate this design information to the various meeting participants (Figure 7).  Figure 7: Different drawings are often used at the same time while performing a meeting task.  An artist’s rendering of a façade, for example, may show the material characteristics of the cladding, but participants may need to refer to a partial section of the façade or a plan view in order to find other kinds of information about the façade.  Domain-specific   40 design drawings usually focus on the specific system designs.  While a mechanical drawing contains information about the HVAC system, participants may need to use structural or architectural drawings at the same time, in order to check interferences or other issues. We also observed that consultants were having difficulties in finding the information they need in other consultants’ drawings. Physical dimensions or the weight of a component are not necessarily shown in detail in these drawings, though some consultants may need this information in order to adjust their designs. For example, a structural engineer might need to know the weight or the material of a fuel tank in order to finalize the slab calculations of that particular area. An architect might need to be able to visualize the 3D characteristics of a mechanical or electrical component in order to design the required space accordingly. Table 15 describes several bottlenecks that were observed as a result of drawing content limitations. Bottlenecks related to the limited interactions with the drawings are listed under the “interaction/access” subgroup. Even though these bottlenecks are related to the drawings, the main reason for the bottleneck is the limited interactions with the drawings.   41 Table 15: Sample data related to drawing content bottlenecks Structural Consultant: "...these are beefy walls." Mechanical consultant: "Are there any piping going through them?" Since structural drawings focus on information about the specific design, possible clashes with other systems can not be observed on these drawings. (CIRS_ February 11, 2009) “How physically big is this thing” architect to mechanical consultant. (Question is about the physical dimensions of a mechanical component) CM; “ there is no fire separation required between these areas?” (Question is about the code requirements of an area in the building) This information is not included in the mechanical design drawings but other consultants need to know these in order to change their design accordingly. (CIRS_ January 21, 2009) Consultants are discussing the space requirement for the cistern. Mechanical drawings do not represent all the information  that other consultants need to know about the system component during decision making. Consultants' questions about the cistern: "How big is the tank?",  "Why is it (the size of the tank) an issue?", "What is in the cistern, is it chemical?"  (CIRS_ April 01, 2009) CM asks architect a question about the vapor barrier shown on the architectural drawings: “the vapor barrier…what is it actually?” Architect: “let me find it out” (will get back to CM later) CM’s question on exterior blinds: “Are they a part of the costing?” “We will give you that information about the manufacturers” answers architect. The drawing does not contain enough detail information. (CIRS_ March 04, 2009) The architect uses the physical model and the artist’s rendering at the same time because rendering has the ability to represent the visual effect of the materials used on the façade. It is not possible to see these effects on the physical model. Participants can observe more than one facade at once on the model and compare the facade characteristics to one another. (CIRS_ November 12, 2009) Mechanical consultant points to a representation of a component on the drawing and asks what that is. Architect says that he never used that component before in a design. He says he is not sure what it really looks like. That part of the system design was provided by a project technology partner and it was later incorporated into the architectural drawings (CIRS_ February 18, 2009)  Symbols: This section contains the bottlenecks that occur because of misinterpreting the domain-specific symbols in the various consultant’s drawing. Bottlenecks related to the interpretation of participants’ sketches are also included in this section. Each consultant’s drawing used in a meeting contains specific types of information that is intended for the use of different professionals and trades people. While some of these symbols can be interpreted by the consultants, some team members may have problems in understanding or interpreting parts of the drawing content.  For example, an architect may have misread the information about the diffusers in a   42 mechanical drawing, or the CM may not be able to identify the difference in the façade materials on the elevation drawings. The representation of information on drawings may even differ from one design phase to another in the same domain. During the EEEL project’s schematic design phase, architects from two different offices were having difficulty interpreting each others’ schematic drawings. This bottleneck occurred because during the schematic design phase, architects try to communicate their design ideas by using sketch-like representations instead of common architectural language. Team members sometimes need to verbally explain their sketches in order to communicate their ideas. Sketches are not always drawn with the same drawing techniques and level of detail as the design drawings. They are often more informal and used as a quick reference.  Table 16 describes several bottlenecks observed related to the misinterpretation of symbols in design drawings.   43 Table 16: Sample data related with symbols section CM to architect: “Could you let me know which ones are the windows and which are the panels in drawing A301?” It is hard to identify the panels and windows from the drawings because of the way they are represented in the drawings. (CIRS_ March 04, 2009) Orientation of the artifact affects interpretation of symbols: the areas that CM points during his explanation confuse the others because CM misinterprets the orientation of the building on paper drawing. Others show the north on the drawing to CM. (CIRS_ October 22, 2008) Architect is pointing on the mechanical drawing, he asks: “is this going this way or going this way and out?” Mechanical consultant: "I think it is going this way". Architect: "So this is the high point. Which way is the water flowing?" Mechanical consultant: "Well it is flowing in both directions." (CIRS_ August 13 2008) Architect: we have updated C-4 (Situation control) plan. Mechanical consultant points on the drawing and asks: “what is this?” Architect describes what is labeled as the “storm water tank” which is a part of the sanitary system. (CIRS_ February 18, 2009) Architect explains his sketch of a proposed landscape design component detail to other consultants.Deatil is about making an underground service line visible to the pedestrians. Consultant needs more verbal descriptions because the sketch itself is not enough to exactly communicate the designer's idea (CIRS_ July 30, 2008) “Those pink planks, are those… what are they?” pointing the drawings pinned up on the wall. (EEEL_ April 17, 2008_ 2' 00" of the recorded video) Vancouver and Calgary offices are having a distributed meeting (shared desktop, audio connection over the phone). “I don’t know how you illustrate good noise or lack of bad noise” (27' 24").  “I couldn’t understand that-time volume (diagram)” (29' 57"). Vancouver: “What’s the horizontal green line supposed to mean?” (Nobody seem to know what it exactly refers to_ 50' 06"). (EEEL_ January 18, 2008)  Visualization: In traditional practice, designers use different formats of drawings to represent various design information. For example, an elevation drawing in an architectural drawing set may not be enough for a user group to fully understand how the building façade would look when the building is finished. Consequently, a colored artist’s   44 rendering and a façade detail might also be used in combination with an architectural elevation plan to better communicate the design intent. Designers often need to verbally describe components, or use gestures or sketches to communicate information that can not be visually represented in the drawings. Meeting participants may need to mentally visualize the characteristics of the design which can not be clearly represented on the drawings. The necessary information is not always easily accessible from the drawing representation. Paper drawings (especially 2D drawings) have several shortcomings in terms of clearly visualizing design information. Plan drawings usually represent the components within around four feet distance off the floor plane (cut plane) in satisfactory detail. However, it is not easy to understand systems or components that are above this cut plane by looking at a 2D plan drawing. It can be hard to observe an issue about a vertical component that is repeated on each floor, since participants may need to mentally overlay corresponding plans on top of each other and try to picture the possible outcomes in their minds. Sometimes the participants face problems getting oriented in the drawing when the group is using more than one set of drawings placed on the table, each facing different directions.  Table 17 describes several examples related to these visualization bottlenecks.             45 Table 17: Sample data related with drawing visualization bottlenecks Landscape design update by architect: he talks about a number of clashes between the landscape and architectural design elements. He verbally describes where the building structure and the landscape design components clash. During this discussion he does not use any drawings. (CIRS_ March 04, 2009) It may be hard for some participants to visualize the 3D physical characteristics of a building component on a 2D paper drawing. Mechanical consultant: "This wall is full height I think" Structural consultant: "Yes" Mechanical: "How do you access to this side?" Structural: "There is an opening" The opening is not represented in the drawing because it is above the cut plane. (CIRS_ February 11, 2009) “So the equipment is tall?” Architect is evaluating different options about a mechanical room layout. He is asking the mechanical consultant about the physical characteristics of some mechanical components. The 3D charecteristics of the equipment is not represented in the drawing so they have to mentally vizualize the component in order to evaluate different layout options. (CIRS_ February 25, 2009_ 20’10” in the recorded video) Discussion about the mechanical drawings: Architect: what is going on over here? (He points on the drawing) Mechanical consultant explains the information represented in the drawing.They are trying to visualize the mechanical system routing by verbally explaining the routing and components. Mechanical gives his update by using a 2D plan drawing. The drawing outlines the architectural plan and elements, but the mechanical system components were hand drawn. (CIRS_ February 18, 2009) The update is about different properties of slabs (thickness, differences in elevations etc), lateral forces affecting the design, other structural design elements that might have influence on architectural, mechanical or other consultants’ designs. Only the plan drawing is used while the structural consultant verbally describes the issues with the help of gestures he makes on the drawing. (CIRS_ February 11, 2009)  4.2.2. Interaction/ Access Design teams use information artifacts, such as drawings, documents and physical models, while they perform meeting tasks. In order to perform their meeting tasks more efficiently and effectively, they need to easily access and interact with these artifacts. In this section, I categorize and define the interaction and access bottlenecks observed during this study. Interaction and access bottlenecks are grouped under five topics: remote pointing, annotation, navigation, visibility and manipulation. Remote Pointing: Unavailability of tools for remote pointing (to be used on digital and physical artifacts) creates interaction bottlenecks, which slows down the meeting processes and interrupts the work flow.   46 Since there were no tools used that support remote interaction, participants had to get close to the information artifact or the display in order to point or reference the area of interest.  While a wireless mouse or other technologies can be used for pointing to the digital data, I observed difficulties in pointing to physical artifacts even if the participants used a laser pointer. Since the participants sit around a table and the stick set (or physical model) is located in the center of the table, it would still be hard to point to areas on a paper drawing (unless the drawings are displayed on a vertical platform). Usually the participants sitting away from the drawings used verbal explanations and references to other parts of the design in order to define an area of interest on the project drawings. Some participants did not use the information artifacts which were available in the meeting room, just because they didn’t have the proper tools for remote pointing. We also talked about these issues in the section on “access to tools and artifacts,” but here I focus on pointing specifically.  Table 18 describes several bottlenecks related to ineffective remote pointing capabilities.            47 Table 18: Sample data related to remote pointing bottlenecks Electrical consultant is giving an update about existing transformers on the site. he is sitting in his chair, he is away from the drawings. Architect tries to find and point to the area that the electrical consultant is talking about on the site plan. He manages to do this after a couple of directions from the electrical consultant (electrical consultant could have done this faster himself if there was a remote pointing tool available). (CIRS_ July 30, 2008) Mechanical consultant has to stand up to point to some information on the documents that are in front of the architect. Note that these documents are in front the architect and only he has access and better view of the information represented on the drawings. (CIRS_ March 25, 2009) Mechanical consultant is reaching over the table to point out the dimension he needs to know in order to size his diffusers. He is also explaining to the architect why this dimension is needed. He needs to know the height of the risers in the auditorium. (CIRS_ January 28, 2009) Electrical consultant is pointing to the drawing during his design update. People sitting around the table have to stand up in order to be able to reach and point to something on the drawings. Not all the participants have a clear view of the drawing or of what is being shown on the drawing. (CIRS_ April 01, 2009_ 1:29:00 of the recorded video)  Annotation: Team members perform sketching, annotating, and note-taking activities on different information artifacts for various purposes. Annotation is used to clearly express an idea, propose a design change, and create a meeting notation (annotation on the side of a drawing about the proposed change or a decision). Annotation bottlenecks involve making annotations on physical and digital artifacts, communicating an idea using sketches, note-taking, viewing and manipulating annotations of other people, keeping a record of these annotations, etc.  During my observations, I noticed a variety of information artifacts were used for annotation, including the whiteboard, Smartboard screen, sides of a paper drawing, paper   48 drawings, and personal notepads. I observed that sometimes the annotations made on the Smartboard screen were of a lower quality than the person’s handwriting on a paper. Most sketches I observed were temporary and there were no records of the sketches made on surfaces other than the ones made on actual drawings. Viewing the sketches was often a problem since participants who were sitting further away did not have a clear view of the information. It was hard for the participants to follow the sketches that were made on personal notepads. Participants usually had to stand up and get closer to an information artifact, in order to perform sketching and annotation.  When annotations were made on drawings, either on a display or on paper, it was hard for some participants to reach over and change or manipulate the annotations since there were no available tools to support these interactions. When consultants were proposing or discussing possible design alternatives, they mostly used verbal explanations and sometimes sketches to express the idea. While this method is quick, it also assumes that everybody clearly understands what is being proposed. On the other hand, during my observations, the participants seemed to understand what was being proposed verbally. Traditional 2D drawings do not allow temporary sketching or manipulation of the drawing content which would be useful tools when discussing changes to a design. Table 19 describes several of the annotation bottlenecks observed.   49 Table 19: Sample data related to annotation bottlenecks Electrical consultant is marking a component on the drawing during his design update. Not all the participants have a clear view of the drawing or of what is being drawn on the drawing. Note that some participants have to stand up to view the drawing better. (CIRS_ April 01, 2009_ 1:28:48 of the recorded video) The archietct is analyzing two issues about the energy modeling: energy balance and reduced possibility of losses. He sketches on the whiteboard to better communicate his question about the energy modeling.  He has to stand up and move to the board each time he wants to sketch something on the board. The task could have been performed more efficiently if there were tools to support remote annotation on a display. (CIRS_ March 11, 2009_ 37’36” of the video recording) While other participants are discussing an issue on the board, the architect is sketching a detail on his notepad, which will be used in a minute to help to solve the discussed issue. If he could have used a common display and made his sketch remotely on this surface, maybe he could have helped the others solve the issue faster, and the other people would be able to view the explanative sketch much easier on the display rather than trying to see the sketch on the notepad.  (CIRS_ July 16, 2008_ 12' 56" of the second meeting DVD) Navigation: Project teams use paper and/ or digital sets of design information during the coordination meetings. Participants often refer to these information sets throughout the meetings. During our observations, navigation bottlenecks were observed when the participants were searching for the most relevant data amongst different forms of information sets. Problems with navigating the drawing set and looking for the most relevant document in a set of documents are included in the navigation bottlenecks. Navigation bottlenecks were observed during both digital and paper based meetings we attended. Navigation in the stick set caused bottlenecks because the team members experienced difficulty finding and accessing the right drawing in an efficient way. Because of the size of the drawing set, it was hard to flip pages. If multiple sets of drawings were to be used at the same time, the drawings took too much of the table space. There were times when the participants simply preferred not going through the   50 pages to look for a drawing because it was easier to verbally describe the problem area to others. In digital meetings we observed that it was easier to navigate through the pages of a drawing set since the interaction of the specific software available (Revit) had a user defined list of pages of the drawings which was accessible from the screen (Figure 8).  Figure 8: The list of drawings in Revit software helps the users to move easily in between different drawings.  However, when multiple drawings were to be opened on the same screen, it became difficult to view the drawings given the limited screen space. Participants sometimes preferred to use smaller scale (A4 size) floor plan drawings instead of the full size set (for example when they wanted to compare components on multiple floors). It was easier to navigate between smaller scale drawings because they are more manageable and one can put the different plan drawings next to each other to observe layouts on multiple floors. This made it easier to compare floor plans than you would on a full size stick set. Multiple A4 size floor drawings required less table space than one full size plan drawing page. I believe that if these favorable characteristics of smaller scale drawings can somehow be adopted into digital tools, design teams can navigate the different sets of drawings more efficiently.   Table 20 describes several of the navigation bottlenecks that I observed.   51 Table 20: Sample data related with navigation bottlenecks There are yellow stickers used for bookmarking special pages of the code consultant's drawing set, in order to make navigation easier. This kind of adjustments are needed for improving the efficiency of the design teams when they need to navigate in the drawing sets  (CIRS_ April 15, 2009: Snapshot from the 58:58 of the recorded video showing the bookmarking on a drawing set) Navigation through the pages of the stick set: Electrical consultant is trying to find the detail drawings page about emergency generator (it takes him 31 seconds to find and open the page).  Later he moves to the plan drawing page to show the proposed location to the architect. (CIRS_ April 01, 2009_ 1:27:46 of the recorded video) During the discussion about the location of the heat pumps in order to optimize the cost, it takes about 15 seconds for the mechanical consultant to find the related mechanical drawing in the drawing set.  He goes through the pages of the drawing set one by one to find the page with the right drawing. (CIRS_ March 11, 2009) The architect is going through different plan drawings to point out areas on floor plans while discussing space requirements for the supply and return for the cistern (a component of the mechanical system). He has to spend 18 seconds to find the first related drawing page in the drawing set. Then he flips back and forth the different plan drawings when he is talking about the mechanical system routing. (CIRS_ February 25, 2009_ Picture from 21’:00” of the video recording)  Visibility: During the coordination meetings, design teams use a variety of representations of design information to communicate the design content. It is important for each member to be able to view these artifacts to efficiently understand or describe a design related issue. During my observations, there were often times when the team members had problems viewing the artifacts individually or as a group. The effect of this problem was not usually noticeable from the workflow perspective. Visibility of the information artifacts was noted as a bottleneck during my observations, since it was one of the most common observations. Frequency of the observed visibility problems indicates the need for improvement in current meeting settings. This section includes all   52 kinds of viewing problems (group viewing, individual viewing etc.) that were observed while the participants were working with different forms of information artifacts. The main cause for the visibility bottleneck was proximity to the information artifacts. When the team used the paper drawing set, the drawing set was usually placed in the middle of the table or in front of the speaker and some of the participants did not have a clear view of the artifact. In digital artifacts, the visibility bottleneck was related to the display location. According to the display location, some participants were not able to easily follow the information displayed on the screens. Room layout and seating arrangement can also be listed as the reasons for this bottleneck. Visibility of the sketches that were made on personal notepads was often a problem for most of the participants. When a consultant handed out documents during a meeting, participants would often focus on their copies of the document. In this case the information was actually visible to everyone but the group lost a shared focus. Participants often had difficulty when they needed to view a physical model during the meetings. In one of the meetings, during the structural consultant’s design update, other participants had to take turns to look at the physical model in order to better understand the areas that new structural bracings were needed. I believe that presenting the information on displays that can be remotely controlled would solve some of these bottlenecks. Instead of placing the drawing set or a document on the table, displaying it on an interactive display would help improve the visibility of the information and would also improve the group focus. Visibility of a physical model by all participants can be improved by using 3D models displayed on   53 monitors. This way, all participants can view the model from the desired angle.  Table 21 describes examples of some of the visibility bottlenecks that I observed.   54 Table 21: Sample data related to visibility bottlenecks (a) (b) During the structural design update, structural consultant hands out copies of his drawings and explains number of issues on these drawings. He points to the drawings as he speaks but mostly he is pointing to the drawing that is in front of the architect. The architect sketches a detail on his notepad to explain his thinking. The other people are busy with viewing their copies. The group focus is not on the same point.  (CIRS_ July 30, 2008) One of the design architects explains the façade design and he uses the physical model on the table for orienting the others and showing the locations of the different proposed facade materials. Some participants have limited or no view of the areas that are being shown. (CIRS_ July 23, 2008_ 12' 57" of the recorded video) Only the structural consultant has a clear view of the areas he is pointing on the physical model, as he talks about where they might need bracing. Later the mechanical consultant needs to view the physical model to better understand these areas.  (CIRS_ July 16, 2008_ 59'50") Mechanical consultant gives his design update from a drawing (there is only one copy) which is close to and oriented towards the architect and the mechanical consultant. Only they are able to see the fine print on the drawing and only they have a good view of the drawing. It looks like as if they are having a private conversation or as if the design update is being given to only the architect. (CIRS_ October 15, 2008) Structural consultant’s update on his design drawings. Architect stands up, stands next to the structural consultant during the update. Other consultants also stand up to get a better (?) view of the drawing. The consultant opens up the drawing set in front of him; it is not even placed in the middle of the table where the others have a better chance of visibility.  (CIRS_ February 11, 2009) (a) Participant is moving the file closer to himself to look at a particular information. (b) This time other consultant has to stand up to see what is being shown to the architect. (CIRS_ November 5, 2008)     55 Manipulation: Traditional 2D drawings do not allow many interactions that the project teams needed to perform during a meeting. Manipulation of represented information on paper drawings is often hard or impossible to perform. Manipulation includes interactions like changing design information, getting quick measurements from a drawing, clearly identifying all design components in a 2D drawing, comparing multiple floor plans with each other, etc. Not having the capability of such interactions affects the efficiency of the team and the information flow between participants during the meetings. When using the traditional stick set, teams are limited with the section views that are indicated on plans. One cannot derive and move to a desired section view from a plan view. Clash detection between systems cannot be effectively done on 2D drawings. Since the traditional 2D plan drawings are meant to represent what is below the cut plane, it is not easy to understand systems or components that are above this plane. With the traditional 2D paper drawings, team members cannot easily overlay two or more system drawings on top of each other and compare multiple drawings with each other. It is harder to get instant and accurate dimensions from a traditional 2D drawing, unless the particular measurement is shown on the drawing. When participants would like to observe an issue about a vertical component that is repeated on each floor, it is hard to view the required information on a traditional stick set. When using a traditional stick set, people sitting around a table have different viewing angles, and the drawing is oriented towards the person who is using it. Other team members may be disoriented when one or more drawings are used at the same time and if these drawings are laid on the table in different positions. In this case the   56 bottleneck is a result of not being able to adjust the viewing angle according to each viewer (when needed). Most of the time when consultants are proposing design changes on a 2D drawing they explain the proposed change but do not perform the actual change on the drawing. During the meeting, proposing ideas seem to make sense but when the actual change is made, there might be problems with other parts of the design; there might be clashes with other components or other system designs might need to be adjusted according to accommodate the proposed change.  Table 22 provides several examples of manipulation bottlenecks.                               57 Table 22: Sample data related with manipulation bottlenecks Architect mentions the suspended slab design at loading deck area: “Is that going to be enough in the loading deck? Right underneath it there are washrooms. There is drop in that particular area. A truck can back into that. ” Architect recommends structural to check the suspension slab thickness for that particular area. Architect refers to the plan drawings on the board as he describes the issue but there are no section drawings available from the area.  Within four minutes owner's representative wants to see what's going on in the same area and asks for a section view. Since there is none available, architect starts drawing a sketch on the board. It takes little over a minute to sketch the section on the board and explain the issue to the owner's rep.The problem would have been communicated faster if the teams could get instant sections by pointing on the plan drawings, but paper drawings do not allow this kind of manipulation of the plan drawings. (CIRS_ August 13, 2008) Architect and the plumbing consultant both stand up close to the drawing which is located in the middle of the table. They are pointing on the drawing and discussing the plumbing system. They verbally describe their ideas, but they cannot actually make the proposed changes on the drawings to observe the results. Discussion is about the plumbing system layout for the janitor rooms. Architect: "How do you want this?... If we flipped this back here?" Plumbing consultant: "I will just T off this here."  (CIRS_ March 4, 2009) Electrical consultant asks while pointing on the drawing: "How thick are these walls?"  The wall type can not be instantly derived from the 2D drawing and he cannot get instant measurement on the drawings. Structural consultant goes through his drawings to find the relevant information while electrical consultant explains why he needs to know the thickness of the walls: "Because we will have to drill through these walls." After 31 seconds structural consultant gives the wall thickness.  (CIRS_ August 20, 2008) Architect asks structural consultant the distance of a column from a wall. The dimension is important because the column was recently pulled out from its previous location in the architectural drawings. The architect goes on to explaining why the column was moved out. Structural consultant says that he will check the new size of the column according to the architectural design. Intended action was to check the structural drawing's compliance with the most recent architectural design. But it took longer to explain the issue to everyone during the meeting (CIRS_ August 13, 2008) Design team is using a smaller scale paper drawing. Plumbing consultant needs to zoom in on the problem area to take a measurement but he can not perform this interaction on the paper drawing. “I have to measure this distance. I have to blow this up” Plumbing consultant says as he is trying to answer architect’s question about the spacing of the sprinkler heads. The architect's question remains unanswered since the required manipulation (blow up and measure) can not be done on paper drawings. (CIRS_ March 04, 2009)  4.2.3 Information There is great amount of information involved in the design process. The design information is created by consultants from different companies. Information is shared between the consultants and each consultant’s design has to be coordinated with the others’. Management of the design information plays an important role in the success of the project. This section includes the bottlenecks in information exchange between   58 consultants, bottlenecks caused by information interdependencies between design information, and information availability bottlenecks in the design coordination meetings. Exchange: In all phases of a project, a great amount of information is exchanged between consultants. The design progresses fast, especially in the early design phases. Consultants have to coordinate their designs according to the changes in the architectural design and sometimes according to the design constraints of other consultants. These characteristics of the projects make information exchange an important factor for success. During my study of the coordination meetings, I observed bottlenecks that were a result of delays in information exchange between consultants. There is often a time lag between a design change and notification of other consultants. Sometimes consultants learn about a design change or hear about a design decision for the first time during a coordination meeting. Not having instant access to or notification about the progress and changes made in others’ design documents causes inefficiencies, and creates bottlenecks in the information flow. Teams sometimes end up wasting time by working on outdated design information. The teams need effective and efficient methods for exchanging design information. Methods used for information sharing between the team members or not having an effective method of sharing information was observed to cause bottlenecks in my study. Frequently receiving amendments to drawings or documents may lead to confusion or frustration in information exchange. Not having a method to monitor the versions of documents (not having a specific way of naming documents etc.) can create bottlenecks navigating in or exchanging large sets of information. If there are no common   59 formats used for preparing and sharing documents and drawings, some parts of the information may get lost or it may get hard to trace back information. In the CIRS project, since every consultant created a project model from scratch, the drawing sets were not completely integrated. This leads to inconsistencies between design drawings since changes in one consultant’s design were sometimes not integrated into other’s drawing simply because the second person was not notified about the change or was notified late. Table 23 summarizes some of the information exchange bottlenecks that I observed. Table 23: Sample data related with information exchange bottlenecks: Design team is discussing the auditorium design. It turns out that the CM, who is working on the project's cost estimate, is not working with the latest version of the design drawings. CM was not informed about some design changes. CM's representative: “the drawing that I am working with right now doesn’t have that detail.” This means that his budget calculations, that were discussed during the meting, were from an older version of the design drawings (CIRS_ March 4, 2009) CM mentions some discrepancies that he noticed between architectural and structural drawings. CM also mentions a number of inconsistencies on the structural drawings. It turns out that there have been some changes to the design drawings but CM does not have the updated drawings. CM had been working with the older drawings. CM ended up mentioning a number of issues during the meeting, most of which were already coordinated between architect and the structural consultant, but were not shared with the CM. (CIRS_ February 25, 2009) Architect explains that all the shop drawings and information about some system components were being sent only to owner's representative by the technology partners. But some of this information was not forwarded to the consultants who were supposed to integrate this information into their designs. The architect hasn’t received any shop drawings about some mechanical and electrical components that were represented in the architectural drawings. So he doesn't know what some of the components in his design actually look like. Participants decide that everything should be sent to the architect. (CIRS_ February 18, 2009)  Interdependencies: The design consists of a number of information sets from different domains. Design discussions are multidimensional and interrelated with the decisions made by other consultants. While each consultant is working on a separate system in the building, they still have to work together and coordinate their work with others. During   60 the coordination meetings, consultants have to evaluate scenarios together to come up with a solution that works well with everyone’s design criteria. The issues that are discussed during the meetings involve many parameters. These parameters may be related to more than one domain at once. That’s why discussion of a topic sometimes triggers another discussion. The design team usually moves on to the next agenda topic without solving the previous one if more time is needed to analyze a proposed solution. Sometimes consultants have to wait for others’ designs to progress more, in order to derive the information they need for their progress. Because of many factors, system designs may not be progressing at the same level of detail. When there are lags between the progress of different designs, important information which is needed by a consultant may not be detailed enough in the other consultant’s design. This creates a bottleneck since a consultant’s design decisions may be based and/or dependent on the missing information in the other designs. These lags in between design progresses may slow down the progress of others. I observed one instance where the mechanical consultant admitted that the architect wanted some information from the mechanical consultants a week ago but they still were not finished with that part yet after a week. I observed multiple times where the architect complained about the progress of the mechanical design being unsatisfactory. Several times, the architect asked other consultants to improve their design so that the architectural design team could use the information to finalize the design of sections of the building. There were times when the architect’s questions remained unanswered during the meetings, because the designs of other   61 consultants were not detailed enough.  Table 24 describes several examples related to information interdependency bottlenecks. Table 24: Sample data related with information interdependency bottlenecks Architect needs to know the mechanical component sizes and required areas for the mechanical system components in order to be able to lock down the shaft sizes. Mechanical design has not progressed enough to include this information yet. (CIRS_ February 18, 2009) The method of the use of the roof area affects the size of the beams in the auditorium; this affects the depth of the beams in the auditorium roof which also affects the visibility inside the auditorium.  The sprinkler layout has to be in accordance with the roof structure design, and in order to finish the roof design architects need input from the plumbing consultant. But there are no available auditorium sprinkler design drawings yet. Architects give an update by using sketches to show the problem areas to the plumbing consultant. The meeting time is used for explaining why the achitects need the specific information from the plumbing consultant. The team discusses a number of possibilities for the sprinkler layout but no final decision could be made. (CIRS_ November 22, 2008) No costing work has been done because design development is not over yet. Design development can not be declared over because the site issues are not cleared out yet. Cost is one of the most important issues for the CIRS project design meetings and the team needs to control the cost strictly during all design phases.  (CIRS_ October 29, 2008) The owner's representative explains the reasons why they want a storage area in the building. Topic of accessibility to the storage area comes up and the team evaluates the possibility of moving washrooms to the storage area. The solution seems to be depended on interrelated design decisions. Dropping the washrooms might trigger problems with the plumbing. Washrooms can be below the utilities level from the street, but in this case they might need pumps and extra mechanical equipment. The discussion takes too long and the issue remains unresolved. Team decides that they need mechanical consultant’s approval or ideas about moving the washroom to the storage level and they move on to the next issue. (CIRS_ September 17, 2008)  Availability: During the meetings, design teams coordinate project related issues by sharing the available information. When the information is not available; the issues remain unresolved, questions remain unanswered, and the design team moves on to the next topic on the meeting agenda without a final decision. The design team can not make informed decisions when the required information is not available during the meetings. There are three main reasons for this bottleneck; required information is created but not available in the meeting, more information is required to make a decision or the information is not created yet.   62  In one of the CIRS project meetings, the design team lost valuable meeting time because information about the most important agenda item was not available for the meeting. The construction manager was working on the cost estimate but could not finish the work before the meeting and he called the project architect to say that he would not be able to join the meeting so that he could keep on working on the cost estimate. At the beginning of the meeting, the architect said that he even thought of cancelling the meeting but it was too late to inform all the participants.  There were often times during meetings when the project team did not have enough information available to make a final decision on a discussion topic. Information unavailability was observed to slow down or even halt the decision making process and cause extended project design times. Table 25: Sample data related with information availability bottlenecks The main topic of the meeting is the cost estimate information that the construction manager (CM) has been working on. Right before the meeting the CM called the architect to say that the cost estimate will not be ready until Friday and he won't be attending to the meeting. Architect mentioned at the beginning of the meeting that he thought of cancelling the meeting, but it was too late. Having the cost estimate information for this meeting was important. (CIRS_ November 12, 2008) The discussion is about calculation of the size of the emergency generator fuel tank; Q: “How long does it (the generator) have to run?” Q: “Is it thirty minutes (until everybody is out) or does it have to run longer?” Q: “Where does 'the generator has to be able to run for 12 hours' come from?” After discussing the same issue for about fifteen minutes the team understands that available information is not enough to make a decision on the subject. Architect summarizes what information is needed from each consultant and puts an end to the discussion. More information is needed so this info has to be collected before making a final decision. (CIRS_ April 8, 2009) During the discussion about the energy modeling progress, architect says that they will need the information soon from the consultant. Architect: “whenever we ask you, you say that it is really close to completion. Is she (the energy modeling consultant) being pulled into other projects?” Mechanical consultant answers: “No”. The information was requested before, but it is still not supplied by the consultant. Architectural design can not be detailed without the energy modeling information. (CIRS_ March 04, 2009) There are no proper survey drawings available to make informed decisions about the locations of the existing service lines. Consultant’s survey drawings are not perfect either, they claim that they needed more time for better drawings.  The design team can not make final decisions about the services work during the meeting, decisions are delayed to be made later. (CIRS_ October, 2008)   63 Analysis: Building design involves many parameters from different disciplines. Project teams evaluate different design options throughout the evolution of a project, in an effort to find the best fit to achieve the project goals. During the evaluation of different design options, I observed that the teams lack the technological support that would allow the team to run quick analyses of the proposed ideas and design changes. This is sometimes required to analyze the effects of the proposed idea on the other parts of the design (e.g., changes in the structure might impact the mechanical design), or other parts of the project (e.g., impacts of design changes on cost). When these types of analyses cannot be performed during a meeting, teams lose time because they have to wait for the actual design change to see the results of the proposed ideas, or they face design problems because the team finds out later that a proposed change affects the other parts in the system. Available tools and technology in the observed meetings did not have the capability for supporting these kinds of in-meeting analyses.  Table 26 describes several examples of bottlenecks resulting from limited analytical capabilities in meeting settings.            64 Table 26: Sample data related with analyses bottlenecks Partnering consultant asks “what if” questions about the cost: ”what if …… then what would be the incremented cost?” There may not be a quick answer to these types of questions since analyses and calculations have to be done before answering them. It is hard to answer these kind of questions that require evaluation of the design from different perspectives. The perspectives can be related with the effects on cost, effects on other parts of the design and design components, code requirements and so on (CIRS_ December 02, 2008) Discussion on the green wall issue: Auditorium air is given to the atrium. The architect is asking about a heat recovery system "does that affect your duct sizes over here?" Mechanical consultant says that they have to look into it. It is hard to comment on the effect of some design changes without running analyses first. The mechanical consultant has to calculate the new system loads and check with the required duct sizes to find out if the existing duct sizes need to be changed. Since he is not supported with the tools to do the analyses during the meeting he needs to do it later. (CIRS_ January 28, 2009) Architect and the mechanical consultant are discussing the layout of a mechanical room on the plan drawing. Architect asks while he is pointing on the drawing: “would there be major savings if we flipped this room from here to here?” Plumbing consultant: “yes.. I think” Architect: "what would be impact on the cost if the two rooms were flipped?" There is no available tool to instantly analyze the actual effect of the proposed design change from the cost perspective.  The mechanical consultant can not come up with cost information that would give an overall idea about the impact of the design change (CIRS_ March 04, 2009)  4.3  Project Specific Bottlenecks (Ambiguity): This section of the bottlenecks table is added as a result of a project specific bottleneck group that was caused because of the ambiguity involved in the CIRS project. We added this topic to our framework because of the problems caused by the unique characteristics of the CIRS project’s design process and project scope. Unlike most other project teams, the CIRS design team did not have clearly defined users (therefore had limited user input), did not have a solid project scope, and had limited information on space usage. There were also different policies and procedures of the owner since the building was for the University of British Columbia. Some of the project participants were not familiar with these policies at the beginning of the project. These characteristics of the CIRS project created ambiguity which affected the design process and slowed down the decision making process. Ambiguity may not be a part of a common framework where we analyze all meeting bottlenecks, but I decided to use it in this framework since I observed multiple   65 occurrences during my study. There might also be other project specific ambiguity bottlenecks in each project. Therefore, I suggest considering ambiguity when studying bottlenecks in the meetings in future research to further analyze its affect on the meeting processes.  Table 27 describes examples where the ambiguity of the CIRS project led to bottlenecks. Table 27: Sample data related with ambiguity bottlenecks There is ambiguity about the green roof design; how much of it is going to be used, is it going to be accessible, what loads to take into consideration etc. Ambiguity delays the decision making process and final decisions can not be made about auditorium roof structure and roof loads. It is not clear yet if there is a research group that would use this space for research (CIRS_ October 22, 2008) Architect points out that there needs to be sub allocation of area for different customers for finalizing the massing rental space. Still this information is not allocated for each unit but a total area of rental space is given to the design group (July 23, 2008) Architect: "...we are building this thing, we've got no people to occupy the building... it seems to me these are the people who want to occupy the building" (August 13, 2008)  Project and partner management consultant says he thinks that by tender they will have some occupants, and in detail design they will have inputs from these users. There has been ambiguity about the user needs and project program which was affected the design process.  (CIRS_ March 11, 2009)   4.4  Representation and Interpretation of the Observational Data in the Bottlenecks Framework After observing meetings, reviewing the literature and working on the identification and classification of meeting bottlenecks, I analyzed the patterns of the observed meeting bottlenecks in the studied meetings.  Tables 28 and table 29 were created to visualize these patterns. Table 28 shows the observed EEEL project bottlenecks over time and Table 29 shows the observed CIRS project bottlenecks over time. One of the main purposes of Tables 28 and 29 is to give the reader an idea about how repetitive or how often some bottlenecks in the framework were observed during the   66 study. With this information I intended to figure out which bottlenecks were the most commonly observed ones. Another important takeaway from the tables is to observe the different number of instances of the bottlenecks according to the different meeting types, such as the bottlenecks in co-located versus distributed meetings or digital versus paper- based meetings. Analyzing the occurrence pattern of a bottleneck helps to identify the specific requirements that would be needed to avoid the bottleneck. For example, according to my findings, in the paper-based meetings there were more “interaction/ access” bottlenecks observed since the meeting activities involved the use of information artifacts and the participants’ interaction with these artifacts. Therefore, this table demonstrates that there is a need to better support participant interactions with the information artifacts and access to information in these kinds of meetings. Table 28 represents the observational data about the EEEL project meetings where ten out of eight observed meetings were distributed meetings. The larger number of meeting bottlenecks were observed under the “technology” bottlenecks group. Table 29 represents the observational data about the CIRS project meetings where all of the twenty nine observed meetings were co-located and mostly paper-based meetings. The larger number of bottlenecks in the CIRS meetings were under the “interaction/ access” bottlenecks group. About sixty five percent of the observed bottlenecks in the CIRS project meetings were from the content-based bottlenecks group. Therefore, these tables also demonstrate the specific requirements for different meeting settings. Different kinds of bottlenecks were observed when studying co-located and distributed meeting groups. I observed that when meeting groups are not supported with the right technology, there are additional bottlenecks in distributed meetings. When the   67 groups were distributed, the bottlenecks were mostly related to technology and meeting support tools. During a distributed meeting the participants had very limited or no interaction capabilities with the information artifacts used by the other team.  During the co-located meetings there were still bottlenecks related with interaction with the information artifacts, but in the worst case participants were still able walk across the room to interact with an artifact, or they passed around a document or a physical model for viewing, or they were able to bring a document from downstairs or pull out a document and show it to other consultants during the meeting. Where the groups were in close proximity, there was more social interaction, group discussions shifted to other parts of the design more easily. However when the groups were distributed participation to discussions by the team in Vancouver was limited. Nunamaker et al. (1991) in the study of the electronic meetings mentions that their explanation for the performance effects in their laboratory experiments was that distributed groups remained more task focused than the proximate groups. During one of the meetings, the CIRS project architect mentioned that they sometimes prefer face to face (co-located) meetings instead of having an online conference meeting because it is much easier to pull out the needed information (access to information is easier) during such a setting. During the distributed meetings where there was no video connection between the two offices it was very hard for the participants to tell which or what part of an information artifact was being used or pointed to during a discussion. For example during one EEEL meeting, the designers in the Vancouver office could hear the sound of flipping through the pages of a stick set. But these designers had no idea which drawings were being used or what was being pointed at during this time. When access to   68 information artifacts was limited, people often had to use longer verbal descriptions when they were talking about a part of the design. Areas on a drawing were defined with the grid lines or by the neighboring spaces on the drawings instead of being shown on the drawings.  During the distributed meetings, the architects in the Vancouver office often had a hard time understanding who made a comment since all they had was a telephone connection between the two offices. It was also harder for the Vancouver office to break into the conversation that was held in Calgary office, since people usually use the advantage of body language or presence when they need to comment on something during co-located meetings and this was missing in the distributed meetings. It was also harder to hear people who were sitting far from the telephone receiver during these distributed meetings because of the poor sound quality. One final note is that when evaluating the meeting bottlenecks shown in Tables 28 and 29, one should keep in mind that the meetings where fewer bottlenecks were observed were not necessarily more productive or more efficient than other meetings. There might be other reasons for why there were fewer observed bottlenecks during some of the meetings, such as less use of artifacts, shorter meeting duration, and the discussion topics might have been more about processes rather than the design itself. Another clarification is needed for interpreting the data represented on the following bottlenecks tables: the number of instances of each bottleneck is according to my personal interpretation of a bottleneck and is limited to the extent of this analysis. In my research I did not consider the overall meeting productivity or efficiency as a part of my analysis.  69  70   71 CHAPTER 5: LITERATURE REVIEW Collaborative work and design meetings in general have been studied from many different perspectives. This section describes previous research in the areas of meeting bottlenecks, interactive workspaces, meeting workspace activity, and artifact use in coordination and design. The last section describes the mapping of this literature to my framework. 5.1 Meeting Bottlenecks There are many causes for bottlenecks in coordination meetings that affect the workflow and processes. One of them is the complexity of the systems used in building design and the amount of information involved in the overall design process. Issia and Rankin (2006) describe the challenges in decision making in the construction industry as; “The AEC industry is an industry faced with continuous impediments that render the process of decision making difficult, and fragmented. In contrast with other industries, stakeholders of the AEC industry usually come from different organizations. That is why their backgrounds, interests, and efforts tend to be different, and divided when working on the same construction project. This understandably creates complexities and conflicts in communication, collaboration, and slows down the group decision making process.” A number of researchers have studied inefficiencies in meeting processes and bottlenecks in meetings. For example, Tory et al. (2008) describes meeting bottlenecks related to navigating digital information, individual information lookup, and accessibility of information. In Liston et al., (2001), they focus on problems with information visualization, interaction and exchange in project meetings.  They describe how use of project models and digital workspaces can help design teams to easily and effectively share and interact with the information.  In Grønbæk et al. (1993), the bottlenecks in daily  72 work and collaboration are divided into three subsections as: bottlenecks related with sharing materials, coordination and collaboration. Navigating different formats of information sets (drawings, digital files etc) is one of the bottlenecks I included in my framework and it has been the subject of much research. Physical affordances of paper versus digital technology are evaluated in the study by Marshall and Bly (2005). Use of gestures in team settings has been described in Tang and Leifer (1988), Bekker et al. (1995), Detienne and Visser (2006). Sharing and being able to modify sketches during the design process is noted as a common interaction that improves the information exchange by Bly (1988). When we observe bottlenecks during such common interactions, we also observe interruptions in the work flow and information exchange during the meetings. Stahl (2005) includes “visibility” and “access to tools and resources”, which are also listed in my framework, in his groupware design principles and talks about why these are important for efficiency. 5.2 Interactive Workspaces There have been many different studies suggesting the need for technological improvement in the collaborative work process of design teams. These studies propose that the construction industry could benefit from the adoption of new or existing meeting technologies and tools. Many researchers have proposed different digital meeting spaces where the design teams take advantage of 3D and 4D models and digital representations of project information. These tools have the potential to improve efficiency in the coordination meeting processes by improving the interaction and exchange of information. For example, Liston et al. (2005) evaluates existing information exchange and interaction approaches in traditional meetings, meetings with 4D models, and  73 meetings with product model support. Andrews et al. (2006) suggests more dynamic means of interaction with the information, 3D model use for better visualization and group analysis, and use of digital tools for documenting the meetings. They also list a number of suggestions to overcome the shortcomings of the existing process. Digital meeting tools have been proposed by different people to help solve the problems related with the use of artifacts in the design meetings as well as visualization and interaction problems. Different digitally supported meeting environments have been designed by many research groups. However the construction industry as a whole has generally not adopted these technologies and there are still bottlenecks in coordination meetings caused by limited technology support. Tivoli (Pedersen et al. 1999) with its Xerox ‘Liveboard’ allows small meeting groups to interact with the displayed information by allowing interactions like note-taking, grouping, regrouping, tearing off the notes on the screen, and saving and documenting ideas etc. The computer mouse is used for pointing and a pen is used for different kinds of interactions in the Tivoli system. i-LAND (Streitz et al. 2002) proposes a group of interactive wall displays (DynaWall), chairs that are equipped with docking facilities or built in  digital displays (CommChairs), and a table top display which allows subgroup interaction with the information (InteracTable). All these meeting technologies and tools are interconnected and meeting participants have access to information from the different tools. The use of the “Luminous Table” (Ishii et al. 2002) in urban planning education for combining digital information and physical artifacts gives the users the ability to run different analyses like day light use, relationships with the neighboring buildings etc. With the adaptation of the camera technology, physical models and the Liminous Table,  74 meeting participants combine the drawings, physical models and digital simulations, which give the users the ability to use the tangible artifacts with digital technology capabilities. Messner (2006) describes the use of an immersive display system with a focus on construction planning activities. They describe the benefits of the system for different projects in support of prototyping, planning, scheduling and communicating the design information. Isenberg and Carpendale (2007) documented detailed research references on collaborative information visualization, hierarchical data comparison systems, and design guidelines for co-located collaborative information visualization systems. The study explains the interactive tree comparison for information visualization and gives examples of different interaction capabilities of the system. The system allows the users to compare and work on different information sets by grouping information and supporting multi- user interaction, which enables individual and collaborative work at the same time on the table top display. Fischer et al. (2002) describes the CIFE IRoom, focusing on the need for collaboration, use of different views, integrated model views, and information on I- Room settings. There is a great deal of research in meeting room technology. However, thinking that all meeting bottlenecks would be eliminated by adopting an existing technology would be naïve. The industry needs a whole set of new technologies which can be developed to support meeting processes. I believe there is still a need for more research to develop new and better technologies to support collaboration and group work in meeting environments.  75 5.3 Workspace Activity In order to better analyze the parts of the meetings, it is important to first understand the activities that the meeting groups perform in a workspace. In their study of small group design meetings, Olson et al. categorizes the meeting activities (Olson et al. 1992). The key finding of his study is that while pure coordination activities take only twenty percent of the meeting time, and evaluation and description activities take forty percent of meeting time. In a subsequent study, Liston et al. builds on this categorization of meeting activities and classifies meeting activities as descriptive, explanative, evaluative, and predictive (DEEP) (Liston et al. 2001).  Researchers have also found that group dynamics plays an important role in collaborative work and may have a significant impact on meeting performance (Nunamaker et al. (1991) and Garcia et al. (2004)), which we have also found in our study. 5.4 Artifact Use in Coordination and Design Meeting participants use different types of information artifacts during the meetings. Artifact use has an important role in design and coordination meetings. Discussions mostly evolve around different forms of information artifacts and the different ways that participants interact with information for different purposes. Tory et al. (2008) describes how a building design team used design artifacts during design coordination meetings. They developed a taxonomy that characterized the different types of interactions that team members had with visual representations of design information during coordination meetings, along with the goals of those interactions. Luck (2007) also looked at artifact use in design and described how artifacts are used to mediate understanding in design conversations.  76 5.5 Mapping of Literature to my Framework Table 30 represents the references that were used during the formation of the bottleneck framework in this study. The different hatch patterns used in the table show the degree of relevance of the referenced work to my definition of a specific bottleneck group.  For example, Liston et al. (2005) contains related information about the “interaction/ access” bottlenecks group in my framework whereas Andrew et al. (2006) covers the same topic but my framework is somewhat related to their work. This means that Liston’s perspective in her study is closely related to my interpretation of the bottlenecks. Whereas Andrew’s work contained leads about the bottleneck but he used a different perspective in the study.  Table 30, therefore, illustrates how my proposed bottleneck framework differs from previous research.  Specifically, it illustrates how my characterization of meeting bottlenecks is similar to the literature reviewed, and it shows the unique bottlenecks that I identified during my ethnographic study.  77  78 CHAPTER 6: CONCLUSIONS, RECOMMENDATIONS FOR FUTURE WORK This research proposes a framework to characterize meeting bottlenecks observed during a 16-month field study of 40 coordination meetings for two building projects. I classified these bottlenecks in a framework that illustrates the nature of the bottleneck, and the frequency of its occurrence in design coordination meetings.  The framework represents two main categories of causes for bottlenecks in coordination meetings: context-based bottlenecks and content-based bottlenecks. Context-based bottlenecks are caused by the people in the design team, the meeting environment and the meeting technology. Content-based bottlenecks are related to the nature of the information artifacts (e.g., drawings and other design information) and the interactions with these artifacts. Specifically, content-based bottlenecks relate to representation of design drawings (e.g., symbols and visual representation), interactions and access to information artifacts (e.g., navigation and annotation), and dependencies on information (e.g., analysis and exchange). This study also provides an analysis of the frequency of different bottlenecks in different meeting settings.  For example, according to my findings, in the paper-based meetings there were more “interaction/ access” bottlenecks observed since the meeting activities involved the use of information artifacts and the participants’ interaction with these artifacts. In distributed meetings, the larger number of meeting bottlenecks was observed under the “technology” bottlenecks group. Therefore, this analysis illustrates the specific requirements for different meeting settings. This study enhances our understanding of the work practice of project teams in design coordination meetings.  It highlights the many ways that meeting efficiency could  79 be improved for design teams in coordination meetings. By using the vignettes in this study, people from different domains can understand the nature of the meeting processes, the techniques used by project teams when coordinating designs, and the different methods used by meeting participants to interact with information artifacts. My hope is that these findings will inform the design of new interaction, visualization, and integration technologies that better support the meeting processes of design teams. I observed a number different tasks performed during the meetings. These tasks included informing others about the design progress, evaluating issues related with coordination, exchanging information, etc. But the participants did not change the actual design during the meeting. The decisions made in the meetings were mainly about how a part of the design should be changed, not the actual act of changing. If the design teams had tools for manipulating the drawings and for quickly observing the results of the proposed changes from different perspectives, the meeting time could have been used to make actual design decisions instead of making suggestions that would be accommodated in the design after the meetings. When a part of the design is changed after the meeting by a consultant, it may be harder to evaluate the effect of the change on different parts of the design. An informed decision making process would improve the overall design and construction processes. Meeting support tools that allow participants to instantly manipulate the design and allow them to evaluate the result of the proposed design changes would shorten the time needed for decision making and save project time. Use of digital models from the early stages of the design would allow the consultants to run different analyses quickly and with greater efficiency.  80 Meeting tools that design teams need during coordination should be developed according to the special needs of the industry. Tools for interacting with different drawings should have the capability of overlaying drawings on top of each other, or support tools for viewing multiple drawings in relation with each other. Liston et al. (2000) suggested highlighting information on different documents and drawings that are displayed on monitors, in order to be able to see the relationships effectively to analyze information more efficiently. Linkages between the different information displayed should also be considered. Different views should be linked to each other in a way that, manipulating an object or a data in one display should be instantly incorporated in the other display windows. This way the meeting participants can follow the results of the proposed changes easily and instantly. I should note the importance of supplying the users with intuitive interaction techniques when proposing new meeting tools. Meeting tools should be easy to use, even for first-time users, to encourage them to adopt the technology into their everyday practice. New technologies for remote interaction with the meeting artifacts, better and integrated information visualization techniques and technologies, new process management ideas are expected to emerge in the studied domain. Researchers have to understand the needs of the users in order to come up with the right tools. According to my observations I believe that when construction coordination meetings are supported with the right digital tools, information sharing amongst team members would improve, people would be able to easily and quickly understand the design issues, and shared focus is also expected to improve the workflow.  81 There were several methods that the design team used to communicate ideas, propose solutions or for plain note taking. Sketching was observed very often during the meetings. It is considered as a useful method to communicate ideas or it is used where the available drawings do not represent information about the discussed issue. Meeting participants used different surfaces for sketching, but it was often hard to share this information with all of the members of the design team. Whenever there was sketching on paper, there was often a visibility bottleneck. Sketching that was made on the whiteboard or on the Smartboard screen was easily visible, but people who needed to change something on the sketch were not supported with remote interaction tools.  I believe that a remotely interactive display system, which can also be used for annotation, would be useful when viewing information as a group. This functionality (displaying an artifact that is the focus of the discussion) can be given to the existing displays in a meeting environment or a dedicated display can be used for this purpose. Public display of information is also shown to improve the group focus. During a discussion, sometimes consultants feel the need to describe an issue from their perspective and according to their domain specific design constraints. Because the participants are from different backgrounds, they don’t necessarily know much about each others’ areas of knowledge. People often feel the need to summarize the design constraints, design and decision parameters in the meeting, in an effort to bring everyone up to date. This process may be seen as a normal way of collaboration but it is an important meeting activity that is often performed and crucial because there are interdependencies between design information. It is important for all participants to  82 understand the design constraints of other team members.  There is a need for better tools to represent these constraints explicitly in a meeting environment. I observed that the number of bottlenecks increased with the use of information artifacts. Most of the bottlenecks I observed involved interaction with the information artifacts. Participants need better means of interacting with the available artifacts. Artifacts should be accessible for each participant. Participants should be able to manipulate the information, or should be able to make queries on the artifacts according to their needs. Participants should be supported with remote interaction tools for pointing, sketching, annotating etc. They should be able to navigate project information which is explicitly linked and visually represented so that the effect of a decision can be analyzed from different perspectives. Navigating the sets of information should be made easier to encourage the participants to actually make use of the available information artifacts during the meetings. This would allow the design team to make more informed decisions during the meetings. Information artifacts should be accessible by all the participants. When an artifact is being used by a participant, other participants should still be able to view or be able to interact with the same, or the digital representation of the same artifact. Personal interaction with the artifact should not hinder the other participants’ interaction with the information. For example when a consultant is viewing the physical model, other members of the group should also be able to view the artifact from the same angle to better understand the discussion point. Tools should allow the instantaneous interaction on the same artifact by multiple people.  83 Project teams need an information repository that can be easily, quickly, and seamlessly accessed on-the-fly by meeting participants during the meeting,  The solution to the navigation problem might be creating a common digital information storage system, in which all the team members enter information regularly and according to a common format. The common format would allow everyone to know where all the information is stored and this would allow for consistency and easy navigation. Maybe the software can be supported with special patches that would allow navigation by voice commands to make interaction easier for the participants. Linking the pieces of project information to each other would also enhance navigation in the data set. Using hyperlinks with in the data base is another proposed idea that would make navigation easier in the digital data sets (Grønbæk et al.1993) Using artifacts of different formats (paper and digital) at the same time has many advantages. Digital display of information is observed to have a positive effect on the group focus and provides more efficient ways of interacting with the information. Paper artifacts have affordances since paper is tangible and users interact intuitively with paper. Project teams can improve their workflow by using both digital and paper representations of information at the same time. A combination of using paper and digital artifacts together means using the advantageous parts of the two forms. A good example for such an interface is Microsoft’s Surface technology. When a tagged artifact is placed on the surface, the system displays different kinds of information related with the artifact. Users can view or manipulate the displayed information by simply touching the screen. As a result of my observations of coordination meetings, I believe that digital tools, supported  84 with paper-based information artifacts, can help participants to make more informed decisions, create meeting memory, and improve overall meeting efficiency. To summarize, there is need for new and improved digital meeting support tools to improve the design coordination meeting processes of design teams. It is essential that any solution for the building industry be easy to use, easily accessible, and flexible. Current technologies offer solutions to specific meeting bottlenecks but project teams need additional support to fully leverage their information artifacts in collaborative settings and to enhance the effectiveness of meeting efficiency and decision-making. These tools should be able to work together within the same system. Design data should be linked to each other and the meeting technology should be able to visually represent these relationships. Improved meeting technologies should allow multi-user interactions and should support the use of paper and digital artifacts simultaneously. Project teams need to be able to view information both publicly and in private to better understand and evaluate discussion topics.  Interaction with different kinds of information artifacts should be supported and the user interface should allow even the first time user to use the system efficiently. This research studied the existing work practice of project teams in design coordination meetings and outlines some requirements for the design of new tools to support this process.  My hope is that by better understanding the meeting process and the bottlenecks observed, we can design technologies that provide better support for the unique needs of building design teams.  In particular, technologies that enable better interaction with information artifacts, seamless exchange of data in meeting settings, and advanced visualization technologies for better communication and decision-making.  85 REFERENCES: 1. Andrews, Annie; Jeff H. Rankin, Lloyd M. Waugh. “A framework to identify opportunities for ITC support when implementing sustainable design standards”. ITcon Vol. 11(2006), Andrews et al., pg. 17. Submitted: June 2005. Revised: December 2005. Published: February 2006 at Editor: T. El-Diraby.  2. Bales, R. F. (1998). Social Interaction Systems: Theory and Measurement. New Brunswick, NJ, Transaction Publishers.  3. Bekker, Mathilde M., Judith S. Olson, and Gary M. Olson (1995): Analysis of gestures in face-to-face design teams provides guidance for how to use groupware in design. In DIS ’95, Designing Interactive Systems, Ann Arbor, MI, pp. 157-166. 4. Bly, Sara A. (1988): A Use of Drawing Surfaces in Different Collaborative Settings. In CSCW 1988, Proceedings of the Conference on Computer Supported Cooperative Work, Portland, OR, pp. 250-256. 5. Borgatti, Steve, Introduction to grounded theory, Analytic technologies, accessed 18 August 2009, <>.  6. Detienne, Françoise and Willemien Visser (2006): Multimodality and parallelism in design interaction: co- designers’ alignment and coalitions. In P. Hassanaly, T. Hermann, G. Kunau, and M. Zacklad (eds): Cooperative systems design, IOS Press, pp. 118-131. 7. Fischer, Martin, Maureen Stone, Kathleen Liston, John Kunz, and Vibha Singhal (2002): Multi-stakeholder collaboration: The CIFE iRoom. In Proceedings of the CIB W78 Conference, Distributing Knowledge in Building, Aarhus, Denmark, June 12-14, 2002. 8. Fruchter, Renate; Kushagra Saxena, Matt Breidenthal , Peter Demian. “Collaborative design exploration in an interactive workspace”. Artificial Intelligence for Engineering Design, Analysis and Manufacturing. Volume 21, Issue 3 (June 2007). Pages: 279 – 293. Year of Publication: 2007. ISSN: 0890-0604. Cambridge University Press New York, NY, USA 9. Garcia, A.C. B., J. Kunz amd M. Fischer (2003). Meeting Details: Methods to Instrument meetings and Use Agenda Voting to Make Them More Effective. Stanford, CA, Stanford University 10. Garcia, A. C. B., J. Kunz, M. Ekstrom and A. Kiviniemi (2004). “Building a project ontology with extreme collaboration and virtual design and construction.” Advanced Engineering Informatics 18(2): 71-83. 11. Grønbæk, Kaj, Morten Kyng, and preben Mogensen (1993): CSCW Challenges: Cooperative Design in Engineering Projects. Communications of the ACM, vol. 36 no. 6, pp. 67-77.  86 12. Isenberg, P. and Carpendale, S. 2007. Interactive Tree Comparison for Co-located Collaborative Information Visualization. IEEE Transactions on Visualization and Computer Graphics 13, 6 (Nov. 2007), 1232-1239. DOI= 13. Ishii, H., Ben-Joseph, E., Underkoffler, J., Yeung, L., Chak, D., Kanji, Z., and Piper, B. 2002. Augmented Urban Planning Workbench: Overlaying Drawings, Physical Models and Digital Simulation. In Proceedings of the 1st international Symposium on Mixed and Augmented Reality (September 30 - October 01, 2002). Symposium on Mixed and Augmented Reality. IEEE Computer Society, Washington, DC, 203. 14. Issa, M.H. ,  Rankin, J.H. , and Christian, A.J. “A framework to assess the collaborative decision making process in interactive workspaces”. Joint International Conference on Computing and Decision Making in Civil and Building Engineering, June 14-16, 2006 - Montréal, Canada.  15. Jordan, B. and A. Henderson (1993). “Interaction Analysis: Foundations and Practice.” Journal of the Learning Sciences 4(1): 39-103. 16. Liston, Kathleen; Martin Fischer, John Kunz. “Designing and Evaluating Visualization techniques for Construction Planning”.  The 8th Annual conference on Computing in Civil and Building Engineering, August, 2000 Stanford University, Silicon Valley, CA, USA 17. Liston, Kathleen; Martin Fischer, Terry Winograd. “Focused sharing of information for multi- disciplinary decision making by project teams”. ITcon Vol. 6 (2001); Liston et al, pg. 69.  18. Liston, Kathleen; Martin Fischer, John Kunz. “Observations of Two MEP iRoom Coordination Meetings: An investigation of artifact use in AEC Project Meetings”, 28 October 2007, CIFE Working Paper #106. 19. Luck, Rachael. (2007) “Using artefacts to mediate understanding in design conversations”, Building Research & Information, 35:1, 28 - 41 To link to this article: DOI: 10.1080/09613210600879949 URL: 20. Maldovan, Kurt D.  and John I. Messner “Determining the effects of immersive environments on decision making in the AEC”.  Joint International Conference on Computing and Decision Making in Civil and Building Engineering, June 14-16, 2006 - Montréal, Canada. 21. Marshall, Catherine C. and Sara Bly (2005): Turning the Page on Navigation. In JCDL ’05, Joint Conference on Digital Libraries, Denver, CO, June 7-11, 2005, pp. 225- 234. 22. Messner, J.I. Evaluating the Use of Immersive Display Media for Construction Planning. I.F.C. Smith (Ed.): EG- ICE 2006, LNAI 4200, pp. 484- 491, 2006.  87 23. Nardi, B. A. (1995). Studying Context: A Comparison of Activity Theory, Situated Action Models, and Distributed Cognition. Context and Consciousness: Activity Theory and Human Computer Interaction. B. A. Nardi. Cambridge, MA, MIT Press. 24. Nunamaker J. F.; Alan R. Dennis, Joseph S. Valacich, Douglas Vogel, Joey F. George. “Electronic meeting systems to support group work”. Communications of the ACM archive. Volume 34, Issue 7 (July 1991) table of contents. Special issue on computer graphics: state of the arts. Pages: 40 – 61. Year of Publication: 1991. ISSN:0001-0782. 25. Olson, G. M., J. S. Olson, M. R. Carter and M. Storrosten (1992). "Small Group Design Meetings: An Analysis of Collaboration." Human-Computer Interaction Journal 7: 347-374. 26. Pedersen, Elin Ronby; McCall, Kim; Moran, Thomas P.; Halasz, Frank G. Tivoli: an electronic whiteboard for informal workgroup meetings. Conference Proceedings on Human Factors in Computing Systems, p 391-398, 1993 27. Stahl, Gerry. “Groups, group cognition & groupware”. Issue Date:  2005. Citation:  Paper presented at the International Workshop on Groupware, CRIWG 2005, Racife, Brazil. Retrieved July 19, 2007 from and 28. Streitz, Norbert A., Jörg Geißler, Torsten Holmer, Shin’ichi Konomi, Christian Müller-Wolfgang Reischl, Petra Rexroth, Peter Seitz, Ralf Steinmetz. “i-LAND: An interactive Landscape for Creativity and Innovation”. Published in Proceedings of the ACM Conference on Human Factors in Computing Systems (CHI’99), Pittsburgh, Pennsylvania, U.S.A., May 15-20, 1999. ACM Press, New York. pp. 120-127. 29. Tabesh, A. Riza and Staub-French, Sheryl. “Modeling and coordinating building systems in three dimensions: a case study”. Can. J. Civ. Eng. 33: 1490- 1504 (2006), DOI: 10.1139/L06-124, © 2006 NRC Canada  30. Tang, John C. and Larry J. Leifer (1988): A framework for understanding the workspace activity of design teams. In CSCW 1998, Proceedings of the Conference on Computer Supported Cooperative Work, Portland, OR, pp. 244-249. 31. Tory, Melanie; Sheryl Staub-French, Barry A. Po & Fuqu Wu. “Physical and Digital Artifact-Mediated Coordination in Building Design Computer Supported Cooperative Work (CSCW)”. © 2008 Springer DOI 10.1007/s10606-008-9077-4. 


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



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


Related Items