UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Identifying requirements for a construction software : a case study of a public sector construction organization Grover, Raghav 2016

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

Item Metadata

Download

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

Full Text

IDENTIFYING REQUIREMENTS FOR A CONSTRUCTION SOFTWARE: A CASE STUDY OF A PUBLIC SECTOR CONSTRUCTION ORGANIZATION by  Raghav Grover  B.Tech., Indian Institute of Technology Guwahati, 2014  A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE AND POSTDOCTORAL STUDIES (Civil Engineering)  THE UNIVERSITY OF BRITISH COLUMBIA (Vancouver)  August 2016 © Raghav Grover, 2016  ii Abstract Over the past 10 to15 years, there has been a boom in the construction software market. Most of these software’s have functionality to support processes like document management, on-site data logging and reporting, and safety management. They simplify the process of entering and storing the data through supporting mobile and cloud-based computing. Several construction organizations are looking to adopt such IT solutions in their existing processes. One challenge they face is identifying the requirements for the software, and ensuring that it meets the needs and expectations of the internal stakeholders. This thesis aims to address this issue. In this thesis, a case study of one such organization is presented; the case organization was looking to adopt a construction software in its Engineering Services division, and facing the challenge of identifying its internal requirements. This thesis uses a structured requirements capture approach, adopted from the domain of software development, and applies it to some of the existing processes in the organization. Semi-structured interviews were used to document the current Business Use Cases (BUCs), and challenges relating to different business areas. Each documented BUC was analyzed to identify the software requirements, which can address the existing challenges and make the processes more efficient. The requirements were validated through using self-checklists, stakeholder verification and expert reviews. The methodology for capturing requirements is presented in a way such that it can easily be replicated by other organizations. Overall, this thesis dissertation highlights on the importance of pulling requirements from the stakeholders, and presents a case of applying systems development approach on typical construction processes. iii Preface For this thesis, the author was solely responsible for identifying the research gap, designing the research program and performing all the parts of the research. The author received continuous support and feedback from his supervisor Dr. Thomas Froese, and co-supervisor Dr. Cheryl Nelms.  An ethics approval was required to conduct this research. The ethics approval was approved by the Behavioural Research Ethics Board at The University of British Columbia. The UBC BREB number is: H15-03066. A version of Chapter 3 has been published in a conference proceeding. Grover, R and Froese, M. T. (2016) “Knowledge Management in Construction using a SocioBIM Platform: A Case      Study of AYO Smart Home Project”. In International Conference on Sustainable Design, Engineering and Construction at Tempe, Arizona in May 2016. The author conducted all the research and wrote most of the manuscript. The second author Dr. Thomas Froese, who is my research supervisor, was involved in providing guidance and reviewing the manuscript.   iv Table of Contents Abstract .......................................................................................................................................... ii	Preface ........................................................................................................................................... iii	Table of Contents ......................................................................................................................... iv	List of Tables ................................................................................................................................ ix	List of Figures .................................................................................................................................x	List of Abbreviations ................................................................................................................... xi	Acknowledgements ..................................................................................................................... xii	Dedication ................................................................................................................................... xiv	Chapter 1: Introduction ................................................................................................................1	1.1	 Introduction ..................................................................................................................... 1	1.2	 Motivation ....................................................................................................................... 2	1.3	 Research Objectives ........................................................................................................ 3	1.4	 Scope of Work ................................................................................................................ 4	1.5	 Research Challenges ....................................................................................................... 4	1.6	 Research Methodology ................................................................................................... 5	1.7	 Organization of Thesis .................................................................................................... 8	Chapter 2: Points of Departure ..................................................................................................10	2.1	 Introduction ................................................................................................................... 10	v 2.2	 Information Technology in Construction ...................................................................... 10	2.2.1	 Mobile Computing in Construction ...................................................................... 11	2.2.2	 Review of Commercially Available Construction Software ................................ 15	2.2.3	 Collaboration Technologies in Construction ........................................................ 22	2.3	 Information Technology (IT) in the Case Organization ............................................... 26	2.3.1	 Organizational Context of IT ................................................................................ 27	2.3.2	 Existing Software Development Process .............................................................. 29	2.4	 Understanding the Requirements Capture Process ....................................................... 31	2.4.1	 Introduction ........................................................................................................... 31	2.4.2	 Volere Requirements Process ............................................................................... 32	2.5	 Conclusion .................................................................................................................... 35	Chapter 3: Preliminary Investigation: A Case Study of Software Implementation on AYO Smart Home Project ....................................................................................................................38	3.1	 Introduction ................................................................................................................... 38	3.2	 Knowledge Management in Construction .................................................................... 38	3.3	 Social Media Platforms for Knowledge Management in Construction ........................ 40	3.4	 SocioBIM Application for Knowledge Management ................................................... 43	3.4.1	 Use Case ................................................................................................................ 43	3.4.2	 Green 2.0 Platform ................................................................................................ 44	vi 3.5	 Case Study .................................................................................................................... 45	3.5.1	 Organizational Context ......................................................................................... 45	3.5.2	 Design and Implementation of Experiment .......................................................... 46	3.5.3	 Post-Implementation Review ................................................................................ 47	3.6	 Conclusion .................................................................................................................... 50	Chapter 4: Organizational Review: Public Sector Construction Organization .....................52	4.1	 Introduction ................................................................................................................... 52	4.2	 Scope of Organizational Review .................................................................................. 52	4.3	 Existing Structure and Technologies in Underground Utility and Project Management Branches .................................................................................................................................... 54	4.4	 Scoping the Research Problem ..................................................................................... 56	4.4.1	 Graduate Internship with the Organization ........................................................... 56	4.4.2	 Interviews with Project Management Office (PMO) and Digital Strategy Group 57	4.5	 Identified Areas for Investigation ................................................................................. 60	Chapter 5: Data Collection .........................................................................................................62	5.1	 Introduction ................................................................................................................... 62	5.2	 Business Events ............................................................................................................ 62	5.3	 Stakeholder Interviews .................................................................................................. 64	5.4	 Existing Business Use Cases ........................................................................................ 67	vii 5.4.1	 Construction-Related Public Communications ..................................................... 67	5.4.2	 Knowledge Management and Collaboration ........................................................ 73	5.4.3	 Daily On-Site Logging and Transfer of Data ....................................................... 78	5.4.4	 Sharing Project Information Between Design and Construction Teams .............. 92	5.4.5	 Implementing PMO Framework ........................................................................... 97	5.4.6	 Implementing Green Operations ........................................................................... 99	5.5	 Existing Challenges ...................................................................................................... 99	5.6	 Identified Business Use Cases for Investigation ......................................................... 100	Chapter 6: Data Analysis ..........................................................................................................102	6.1	 Introduction ................................................................................................................. 102	6.2	 Product Use Cases ....................................................................................................... 102	6.2.1	 Analyzing Business Use Cases ........................................................................... 102	6.2.1.1	 Stakeholder Feedback ..................................................................................... 105	6.3	 Software Requirements ............................................................................................... 105	6.3.1	 Analyzing Product Use Cases ............................................................................. 106	6.3.1.1	 Functional Requirements ................................................................................ 106	6.3.1.1.1	 Construction-Related Public Communications ......................................... 108	6.3.1.1.2	 Knowledge Management and Collaboration ............................................ 113	6.3.1.1.3	 Daily On-Site Logging and Transfer of Data ........................................... 119	viii 6.3.1.1.4	 Sharing Project Information Between Design and Construction Teams .. 133	6.3.1.1.5	 Fit Criterion for Functional Requirements ................................................ 142	6.3.1.2	 Non-Functional Requirements. ....................................................................... 142	6.4	 Software Development: Next Steps ............................................................................ 147	6.4.1	 High-Level Software Use Case Diagram ............................................................ 148	6.4.2	 High-Level Software Architecture Diagram ....................................................... 149	Chapter 7: Validation of Requirements ...................................................................................150	7.1	 Introduction ................................................................................................................. 150	7.2	 Self-Checklists ............................................................................................................ 150	7.3	 Stakeholder Verification and Ratings ......................................................................... 152	7.4	 Review from the IT Group in the Case Organization ................................................. 152	Chapter 8: Conclusion ...............................................................................................................153	8.1	 Conclusion .................................................................................................................. 153	8.2	 Future Work ................................................................................................................ 154	8.3	 Limitations of Work .................................................................................................... 155	Bibliography ...............................................................................................................................157	Appendices ..................................................................................................................................164	Appendix A : Artefacts Associated with Business Use Cases ................................................ 164	Appendix B : Sample Interview Questions ............................................................................. 200	ix List of Tables Table 2.1 Review of Commercially Available Construction Software ........................................ 16	Table 2.2 Construction Management Software Comparison ........................................................ 20	Table 2.3 Social Collaboration Platforms ..................................................................................... 25	Table 7.1 Checklist for Testing Quality of Requirements (Adapted from Robertson and Robertson (2013)) ....................................................................................................................... 151	 x List of Figures Figure 1.1 Research Methodology .................................................................................................. 7	Figure 2.1 Commonly Used Methods for Project Management (Source: JBKnowledge (2015)) 21	Figure 2.2 Commonly Used Methods for Data Collection on Field (Source: JBKnowledge (2015)) ........................................................................................................................................... 22	Figure 2.3 Software Development and Implementation Team Structure ..................................... 29	Figure 2.4 Software Development and Implementation Process .................................................. 30	Figure 2.5 The Volere Requirements Process ( Source: Robertson and Robertson (2013)) ........ 33	Figure 2.6 The Brown Cow Model (Source: Robertson and Robertson 2013) ............................ 34	Figure 3.1 Use Case for SocioBIM Platform ................................................................................ 44	Figure 3.2 Green 2.0 Platform for Knowledge Management ....................................................... 49	Figure 3.3 Social Networks of Participants at Project and Element Level ................................... 49	Figure 4.1 Organizational Chart: Engineering Service (As of December 2015) .......................... 53	Figure 4.2 Construction Software Mind Map ............................................................................... 59	Figure 4.3 Identified Business Areas for Investigation ................................................................ 61	Figure 5.1 Work Context Diagram for Construction Related Public Communications ............... 66	Figure 6.1 Deriving PUC from BUC for Quality Inspection On-Site ........................................ 104	Figure 6.2 High-Level Use Case Diagram .................................................................................. 148	Figure 6.3 High-Level System Architecture Diagram ................................................................ 149	xi List of Abbreviations BUC   Business Use Case PUC  Product Use Case IT  Information Technology PMO   Project Management Office BIM  Building Information Model EoR  Engineer of Record BRM  Business Relationship Manager BA  Business Analyst  UBC  University of British Columbia EA  Engineering Assistant OSSB  Operations Safety and Support Branch xii Acknowledgements I would like to thank Dr. Thomas Froese, my research supervisor, for giving me the opportunity to pursue research under his guidance. He provided me the freedom to explore different research areas and select my own research topic. This taught me how to think like a researcher. His intriguing questions and feedback over the course of this thesis is greatly appreciated. The advice on framing the thesis, research writing, and opportunities to present my work at different forums proved invaluable. His advice on having a one-page summary of your entire thesis, which keeps on evolving throughout, allowed me to continuously challenge my thoughts and assumptions. I feel fortunate to have worked under him, it has helped me develop both professionally and personally. Thank you Dr. Froese.  I would also like to thank Dr. Cheryl Nelms, an adjunct professor at UBC, for agreeing to become my co-supervisor on my thesis journey. It was because of her efforts that I was given permission to conduct the case study with the case organization. I thank her for believing in me and allowing me to conduct this research study. She helped me define the scope of my research, research objectives and provided access to the organization. I sincerely appreciate her patience, and the time she devoted to answer all my questions, and provide continuous feedback on my work. Her encouraging advice on starting the thesis writing early-on helped me keep the research on track and gain clarity on my objectives.  Special thanks to the employees in the Engineering Services, IT and Digital Strategy departments for supporting my ideas and devoting their time to meet with me for interviews and validation of my work.   xiii I offer my enduring gratitude to my fellow colleagues and friends at UBC, who have inspired me throughout my stay here at UBC. I thank them for their patience when listening to my research ideas, and providing useful feedback.  Special thanks are owed to my parents, who have supported me throughout my years of education.  Finally, I thank the Sustainable Building Science Program at UBC for providing funding for this research, through the NSERC grant, and for providing office space to conduct my research. xiv Dedication To Mom, Dad & DJ .1 Chapter 1: Introduction 1.1 Introduction Construction is an information-intensive industry, where documents such as design drawings, project schedules, change orders, safety records, and quality inspection reports need to be shared on a regular basis. The dynamic nature of projects results in new challenges every day. This calls for fast and open communication and a collaborative approach between several stakeholders. Construction personnel have traditionally relied on paper-based tools for sharing information, resolving site issues, and decision making on-site. Many in the industry agree that this approach is cumbersome, error-prone, and time consuming. This paper-based approach often leads to late, inaccurate, inadequate, or inconsistent information; which has made the industry prone to defects, delays, waste and cost overruns. This bottleneck of information communication on construction sites needs to be resolved to achieve an integrated and efficient process (Elvin 2003).The construction industry has also lagged behind other industries–such as manufacturing, automation, and software–in making effective use of lessons learnt from one project. As a result, the same mistakes are repeated in future projects.  Over the past 10 to 15 years, the evolution of Information Technology (IT) has resulted in a paradigm shift of the industry from a paper-based industry to a digital industry. The use of IT in the construction industry is on the rise. It is aimed at addressing the challenges relating to information management, collaboration and knowledge management. The construction software market has witnessed a significant growth with software being developed for document management, construction design, safety reporting, information sharing, daily site logging, and quality inspection. Now, the challenge for organization is to select the software which aligns with their needs and expectations. This thesis aims to address this challenge by using a case study 2 approach. The overall goal is to identify software requirements for the underground utilities (waters and sewers), and Project Management branches in the case organization—a local municipality in Canada. These branches are responsible for design, construction and management of some of the municipal infrastructure projects in the organization. This thesis illustrates the software requirements capture process by applying it within these branches. A structured approach is presented for requirements capture. It makes use of generic templates for writing the business use cases and software requirements. This thesis also highlights the importance of conducting a bottom-up stakeholder engagement process when identifying software requirements. This is done by using a preliminary investigative case study (discussed in Chapter 3), and subsequently developing and applying an internal stakeholder engagement process in the case study organization (discussed in Chapter 5). The different approaches used for data collection and analysis have been illustrated through using examples and artefacts, so that other public or private sector infrastructure delivery organizations can easily adopt this approach and apply it in their respective organizations. Once identified, the requirements can be used by the organization to develop their software or adopt existing software that meets their needs. 1.2 Motivation The motivation for this thesis comes from my personal experience of working at the Project Management branch of the case study organization during the summer of 2015. The main objective of my work was to identify opportunities to improve the sustainability of (i.e., to “green”) the design and construction operations in the Water, Sewers, and Streets branches. I conducted field observations and stakeholder interviews over a period of three months. In addition to identifying opportunities to fulfill the objective, I also observed some challenges communicated by the 3 construction site workers, design and project teams. These can be broadly classified into poor document management, limited sharing of knowledge within and across the different branches, inefficient processes, and issues with using existing software systems.  At the end of my work term, I could envision a few software solutions which could potentially address these issues.  However, I did not have sufficient clarity on the current processes of the organization, and the type of software which could easily fit with the existing culture and expectations of stakeholders. I used this as a motivation for my research and started defining my objectives, the scope of my research work. I conducted a few preliminary interviews with the relevant groups in the organization to explore this idea further. Two branches within the organization–the Project Management Office (PMO) and the Digital Strategy branch–were also looking into potential software solutions for improved construction operations. Coordination with these two branches made it easier for me to align the goals and objectives of my thesis with them.  1.3 Research Objectives This thesis has two primary objectives: 1. To understand the current status of information systems in the design and construction operations in the case study organization, and identity the challenges with the existing processes. 2. To identify requirements for construction software that can address the identified challenges and improve the existing processes.  The secondary objective of this research is to illustrate the requirements capture process for construction organizations looking to adopt software for their design and construction 4 operations. This is dependent on the main objectives, and will be achieved in conjunction with them.  1.4 Scope of Work This research investigated only one public sector organization. This organization is one of the largest municipalities in Canada with an Engineering Services department of more than 1800 employees conducting design and construction of municipal civil works. In particular, the focus was on the underground utilities (water and sewers) and Project Management branches which fall under the Engineering Services Division. The details of these branches is described in Chapter 4. The areas within these branches that were investigated (as detailed in Chapter 4), are as follows: 1. Construction-related public communications; 2. Knowledge management and collaboration; 3. Implementing green operations; 4. Sharing site information; 5. Implementing the project management framework; and  6. Daily logging and transfer of construction data The literature review and the construction software reviewed in Chapter 2, was restricted to the areas mentioned above.  1.5 Research Challenges Key challenges faced in this research are listed below: 1. The case organization did not have their design and construction operations processes mapped. If they were readily available, it would have been possible to increase the scope of this work and potentially move into the software development/selection phase. 5 2. There is a dynamic environment of organizational and process change at the case organization. This results in changing of processes or implementation of a new software specific to different branches. Since the author was not an employee of the organization while conducting the research, it was difficult to be aware of such changes. As a result, sometimes, when a new solution was proposed to the stakeholders by the author, the organization had already changed the process either by implementing software or eliminating it completely. This was one of the reasons for using the agile software development methodology, which is explained in Chapter  3. The final challenge was the author’s limited knowledge of software development before this research was started. The author’s background is in Civil Engineering and Construction Management. As a result, the author spent some time gaining knowledge on developing software, focusing primarily on requirements capture process, before starting the data collection. Once sufficient theoretical knowledge was gained, the author also met with some experts in software development to help refine the methodology.  1.6 Research Methodology This research is essentially the first step of an agile software development process1. The methodology used for the requirements capture, i.e. data collection and data analysis, for this research was adapted from the book titled ‘Mastering the Requirements Process’ by Robertson and Robertson (2013).2 The overall methodology for this thesis is as follows:                                                 1 Refer to Chapter 2, section 2.4.1 for complete description of agile development process 2 Please refer to section 2.4 Understanding Requirements Capture Process for a supporting evidence for choosing this particular methodology and a complete description of the data collection and analysis process. 6 1. Conduct a literature review: to understand the past developments, existing software in the market, and to gain an in-depth understanding of requirements capture process.  a. The literature related to IT in construction with respect to mobile computing, collaboration and project management software was reviewed. This review included journal and conference papers, reports, whitepapers and books. b. Commercially available construction software and collaboration software were reviewed. This was done by using publicly available information about the software and using trial versions whenever available. c. Several books and literature were reviewed to understand systems development processes, primarily focusing on the requirements capture process. This was used to design the research methodology and a structured approach for requirements capture.  2. Conduct Organizational Review: to understand the context of the organization, its goals and objectives, and identify the potential areas to investigate. The review was completed using the author’s own knowledge of the organization and through interviews with the branch and division managers. The business areas and business events for investigation were identified after conducting the organizational review. Business events are a breakdown of the activities that happen under a business area.  3. Develop Business Use Cases (BUCs) of Existing Processes: to understand the as-is process of design and construction operations. Semi-structured stakeholder interviews and on-site observations were conducted to understand and develop the BUCs of existing processes. BUCs are preplanned responses to a business event and are a unit of functionality of the business. 4. Derive Product Use Cases (PUCs): to determine the future processes using the construction software. PUCs are derived from analyzing the BUCs. They determine the extent of work that 7 will be automated and implemented by the software. A detailed example of the analysis is provided in Chapter 6. Semi-structured interviews were used to incorporate stakeholder feedback. 5. Write the functional and non-functional requirements for the software: All requirements were formally documented. Each requirement includes a description, rationale, and fit criterion3.  6. Validate the captured requirements: Once the requirements capture was complete, they were subjected to a review to ensure that they are complete, accurate, and unambiguous. The methods used for validation are self-checklists, stakeholder verification, and expert reviews4. The methodology from step 2 to step 5 is represented by the flow chart shown in Figure for illustration purposes:  Identify business areasIdentify business areasIdentify business events under each business areaIdentify business events under each business areaIdentify corresponding BUCs for business eventsIdentify corresponding s for business eventsDerive PUCs by analyzing the BUCserive s by analyzing the sIdentify the functional and non-functional requirements Identify the functional and non-functional require ents Validate the requirementsalidate the require ents                                                   3 These three terms are explained in section 6.3 Software Requirements. 4 Each validation step is explained in Chapter 7. Figure 1.1 Research Methodology 8 1.7 Organization of Thesis A brief overview of each chapter is presented below: Chapter 2 sets up a knowledge platform for the rest of the thesis and acts as a point of departure. Hence, it is important that the reader reviews this chapter before reading other chapters (except Chapter 3). This chapter presents the literature related to IT in construction and the features of some of the commercially available construction and collaboration software. A brief summary of the status of IT in the case organization is also presented. This is followed by providing an overview of several software development methodologies and the requirements capture process used for this research. Chapter 3 presents the preliminary investigation that was carried out to understand software implementation in construction organizations. A case study of implementing a BIM-based social platform on the AYO Smart Home is presented. The chapter describes a complete research cycle that is independent from other chapters, hence it can be read without reading the other chapters (including Chapter 2). It presents the challenges associated with implementing new software in construction projects and throws some light on stakeholder expectations.  Chapter 4 presents the organizational review of the case organization. It outlines the existing structure, goals and objectives, and use of technology in the organization. It also presents the specific branches and areas which were investigated. It clearly outlines the scope of this thesis.  Chapter 5 first describes the data collection methodology, i.e. stakeholder interviews. It outlines the identified challenges and presents the existing BUCs which were developed through stakeholder interviews. It also identifies the subset of BUCs which will be developed into PUCs. This chapter directly responds to the first objective of this thesis.  9 Chapter 6 describes the data analysis techniques used to convert BUCs identified in Chapter 5 to PUCs and illustrates them through an example. It presents the identified requirements for the construction software along with their description, rationale and fit criterion. This chapter directly responds to the second objective of this thesis.  Chapter 7 discusses the validation techniques used to assess the results of this thesis (i.e. the functional and non-functional requirements for the construction software). Chapter 8 summarizes the entire thesis and discusses its contributions and potential applications. The limitations in this research and scope for future work are also described.  10 Chapter 2: Points of Departure 2.1 Introduction This chapter discusses the developments in the areas of IT in construction. In particular, mobile computing, commercially available construction software, and construction collaboration technologies. The review was restricted to these three areas (within the broad domain of IT in construction) since only they fall within the scope of work as discussed in section 1.4 Scope of Work, in Chapter 1. This is followed by the introduction of the current state of IT in the organization being studied. The final section reviews systems development processes with a focus on capturing requirements for iterative development.  2.2 Information Technology in Construction Historically, the construction industry has been known to be reluctant to adopt new technology; however, this trend is gradually changing. In order to remain competitive and productive in the market, many construction organizations have started investing in technology and realizing its importance (JBKnowledge 2015). As per the report by JBKnowledge, software is being used for accounting, estimating, bidding, project management, design, data logging, file storage and collaboration, and communication in construction organizations (JBKnowledge 2015). In terms of future trends, technologies such as augmented reality, 3D printing, wearable devices, and drones are currently being experimented in some construction organizations.  The subsequent sections present developments in mobile computing and review some commercially available construction and collaboration software.  11 2.2.1 Mobile Computing in Construction Mobile technologies devices such as tablets, smartphones, and wearable computers have become affordable and common place. These devices are like mini handheld computers. They have significant power to support functionalities that were previously restricted to desktop computers. Most of these devices can access the internet, have a touchscreen interface, a GPS unit, a camera, motion sensors, and can run third-party apps. The affordability, ease of use, and power of these mobile technologies has opened a new window of opportunity for the construction industry. This can be leveraged for improving the current ways of operations and communications in the construction industry.  Mobile computing is essentially using a computer (of one kind or another) while on the move. It consists of three components: mobile hardware (such as portable laptops, tablets, smartphones, wearable computers etc.), mobile software (such as operating systems, mobile apps) and mobile communication (through networks as WLAN, 3G, 4G, VPN etc.). It allows users to create, access, process, store and communicate information without being constrained to one location. Mobile computing devices allow data capture at the source, thus eliminating redundancy and making it easier to capture complex information. They ensure accuracy, completeness and conciseness of data. Data capture can be manipulated as required and made available to the end-user in varied formats (Zimmerman 1999). A variety of technologies are built into current mobile computing devices such as GPS, cameras, motion sensors, and voice recognition. These can enhance the ability of the user to capture data and also enable automated data capture. The integration of mobile computing and cloud storage has made it possible to store and access large amounts of data.  12 Some of the limitations associated with mobile computing are issues related to power consumption and battery life, bandwidth and range of networks, security over public networks, interferences due to weather and terrain, and small screen sizes and keyboards. These limitations are gradually become addressed as the technology advances. Mobile computing offers a wide variety of applications across various disciplines such as medical, aerospace, agriculture, defense, construction, manufacturing, and commerce.  The construction industry presents its own set of challenges for implementing mobile computing technologies: a rugged environment, resistance to change, a fragmented nature, difficulty in accessing mobile networks due to remote site locations, and safety issues on-site. Many projects still rely on manual processes and traditional communication tools such as e-mails, faxes and phones to obtain information (Dave et al. 2010); however, the situation is gradually improving. Handheld mobile devices such as smart phones and tablets are now being used on construction sites to perform site inspections, safety reporting, materials management, assigning work orders, site management, monitoring work progress and sharing design information. (Kimoto et al. 2005; Zou et al. 2006).  Over the past few years, mobile applications in the market have been on the rise. These mobile applications have infiltrated in every aspect of our daily life: Google Maps to find directions, Yelp to choose restaurants, Pinterest to share and discover new ideas or interests etc. Even in the professional world, including construction, mobile apps are being used to improve or support daily practices. Software vendors have responded to the needs of the construction industry and have developed several mobile applications. Construction related mobile apps are typically part of a software package sold by the vendor. The trend of allowing staff to use their own mobile device (called BYOD, bring your own device) is catching up in the construction industry and 13 allows for a reduction in the overhead for firms (McGraw Hill Construction 2013). Service providers are developing applications that allow employees to switch between a work mode and a personal mode such as AT&T toggle (AT&T 2015).  Some of the construction management software and their mobile applications related to collaboration and information sharing have been summarized in Table 2.1 presented in sub-section 2.2.2. Most of these mobile applications are based on a cloud environment and can be used offline. The users of these applications include designers, general contractors, subcontractors, site superintendents, foremen, and construction managers.  A mobile tools study conducted by McGraw Hill in 2012 on general contractors and trade contractors revealed widespread use of mobile devices on construction sites. The top three identified areas where mobile devices increase productivity on jobsite are: “communication and problem-solving; collaboration and document sharing; and managing workforce, scheduling and tracking project work.” (McGraw Hill Construction 2013). According to some of the publicly available case studies available from construction software providers, construction companies have benefited in areas such as materials management, information management, project management and collaboration by using these mobile applications on their projects. The sewers department at the City of Cincinnati started using mobile applications for work order management and receiving customer service requests. They reported 30% time savings, and a total of $163,500 hardware replacement and call center cost savings (Flowfinity 2015a).  The City of Sydney has been using mobile applications to manage dispatch and job tracking for field service teams (Flowfinity 2015b). Amey UK automated the process of producing safety dig packs for its road digging jobs, around 280 new jobs daily, which resulted is savings amounting to $365,000 yearly. It also improved the audit trail and provided greater 14 responsiveness (COMIT 2015). Taylor Woodrow, a contractor in UK, replaced the paper-based snagging process by using a web-based application resulting in time and cost savings and better quality of database (COMIT 2005).  These mobile computing technologies allow real-time data flow between design and construction sites. This results in efficient decision making and use of resources, reduction of lead times, and enhanced quality of work (Olofsson and Emborg 2004). Bowden et al. (2006) claim that using mobile IT in construction can lead to reduction in defects, accidents, and waste; it can also increase the productivity and predictability on-site. In their paper, they propose a future construction site scenario that received a postive feedback from the industry; however, some industry representatives showed concern regarding the viability of such technological improvement. Saidi et al. (2002) conducted a case study on six construction field activities; they showed that handheld computers can be beneficial for tasks that require access to large amounts of text information, involve viewing small details of a document, entry of binary data, and filling forms or checklists. The main value-adding factors, they highlighted, are provision of real-time information to the jobsite and the office, and improving the accuracy of information being transferred. Chen and Kamara (2011) proposed a framework for using mobile computing for information management on-site. It consists of two models: an application model and a technical model. The application model explores the interaction between the three independent factors (construction site, construction information, and user) and the three dependent factors (mobile computer, wireless network, and mobile application). Each of these six factors has been further sub-divided into sub-factors to explore the relation between context of the construction site and the requirements for mobile computing. The technical model consists of a presentation layer, application layer, and database layer. It provides the system designers a structure for designing 15 these applications. Ahsan et al. (2007) proposed a conceptual model of a Mobile Collaboration Toolkit (MCT); it uses Personal Digital Assistant (PDA) as the hardware device to support the process of documenting changes on site. They conducted a series of case studies and scenario analysis with industry to define the requirements for the ICT technology. The requirements identified were: fast and reliable communication, efficient logging, access to information, access to different systems and ability to use rich media. MCT supports data types such as audio, video, text and documents. It also allows voice recognition and Voice Over IP (VoIP) for voice communication. Kim et al. (2013) designed an on-site management mobile system to meet three design requirements: information sufficiency, fast communication, and advantageous visualization; these requirements were based on study of past literature by the authors. The system consists of three different layers: client, platform, and database. Site monitoring module made use of construction site image data from on-site CCTV cameras and information from office. A task management module allowed task allocation using mobile devices. It made use of Google Maps and augmented reality technologies for effective visualization. An information sharing module allowed interactive CAD drawing sharing amongst users. This system was then tested on a project, and it showed the potential for improving the current data sharing and communication practices in the construction industry. Venkatraman and Yoong (2009) describe the development of a mobile collaboration tool- ClikiFax. The tool is essentially a mobile facsimile system and also allows users to draw sketches, amend plans and receive instant approvals.  2.2.2 Review of Commercially Available Construction Software Tables 2.1 summarizes a review that was conducted of several of the commercially available construction software that are within the scope of this thesis. The objective behind the review was to understand the existing features and functionalities. The review was conducted by 16 the author by referring to publicly available information on the respective software websites, contacting the company representatives, and also through testing the trial versions of the software.  Table 2.1 Review of Commercially Available Construction Software Software Key Functionalities Platforms Fieldwire (Fieldwire 2016) Plan viewing, Markups and annotations, Site inspections, Safety Reporting, Issue Tracking, Task Management, Scheduling, and cost and hours tracking, Dashboard and Reporting. Integration with Google Docs only.  Desktop, Mobile Apps (iOS, Android, iPad), Cloud Based Aconex (Aconex 2016) Document Management, BIM Collaboration, Mails and Forms, Bidding, Customized Work Flows, Field Inspections, Interface Management, Quality and Safety Management, O&M manuals, Dashboards and Reporting, Customized Sharing of Information Desktop, Mobile Apps, Cloud Based PROCORE (PROCORE 2016) Document Management, Drawing Management, Communication Management, Schedule Management, Daily Logging, Bidding, Contract Management, Cost Management, Reports and Dashboards, O&M manuals. Customizing of process to some extent, integration with MS Project, Primavera, Outlook.   Desktop, Mobile Apps (iOS, Android, iPad), Cloud Based 17 Software Key Functionalities Platforms Vista by Viewpoint (Viewpoint 2016) Document Management, Daily Logging, Resource Management, Project Communications, Estimating, Field Inspections, Safety Management, Customized Workflows and Forms, Integrated suite of products, Work Order Management, Reports and Dashboards.  Desktop, Mobile Apps (iOS, Android, iPad), Cloud Based HCSS Software Suite (HCSS 2016) Safety Management, Daily Logging, Tracking equipment and fuel usage, Equipment Dispatcher, Estimating, Photos, Reports and Dashboards, Performance Reporting, Inspections.  Desktop, Mobile Apps (iOS, Android, iPad), Cloud Based Lessons Learnt Database (Secutor Solutions LLC 2016) Knowledge Management, Reports and Dashboards. Desktop, Mobile Apps (iOS, Android, iPad), Cloud Based BuilderTREND (BuilderTREND 2016) Estimating, Daily Logging, Schedule Management, Task Management, Design Management, Project Communications, Push Notification, Photos, Warranty Management, Customer Management, Voice Recognition. Desktop, Mobile Apps (iOS, Android, iPad), Cloud Based 18 Software Key Functionalities Platforms Jovix (Atlas RFID Solutions 2015) Materials Management (Material Documents and Tracking, RFID, Barcodes, GPS) Custom hardware support Flowfinity (Flowfinity 2016) Design Management, Site Inspections, Safety Management, Document Management, Equipment Management, Resource Management, Daily Logging, Work Order Management. Custom Built, Integrate with existing systems. Reports and Dashboards Desktop, Mobile Apps (iOS, Android, iPad), Cloud Based UDA Construction Online (UDA Technologies 2016) Design Management, Document Management, Daily Logging, Photos, Schedule Management, Employee Messaging, Estimating, Project Announcements and Comments, Customized workflows and forms, Contract Management Desktop, Mobile Apps (iOS, Android, iPad), Cloud Based  To facilitate direct comparison, Table 2.2 shows the features of various software in a tabular format. Each construction software was assessed on the basis of its capabilities for project management, collaboration, uniqueness, and supported platforms.  The criteria for assessment was developed by the author. The author reviewed various construction software as shown in Table 2.1. The author also had conversations with the company representatives of the to gain better understanding of the functionality of their software. This review resulted in identification of 19 common construction software features and upcoming trends.  This combined with author’s own knowledge of project management and construction software domain resulted in developing the criteria for comparing software shown in Table 2.2.  20 Table 2.2 Construction Management Software Comparison  Features AconexFieldwireProcoreVista	by	Viewpoint	HCSS	Software	SuiteLessons	Learned	DatabaseBuilderTRENDFlowfinityUDA	Software	SuiteProject	ManagementDesign	Management	(Viewing,	Editing,	Sharing)      Schedule	Management	(Creating,	Updating,	Tracking)    Field	Inspections	        Safety	Management      *Document	Management	(Upload,	Share,	Store)      Daily	Logging	(Timesheets,	Productivity,	Observations,	Reporting)      Resource	Management	(Materials,	Labor,	Equipment	Tracking)  * *  *Knowledge	Management	(Capture	and	Share	Lessons	Learned) Project	Communication	(E-mail,	Audit	Trail,	RFIs,	Change	Orders)     Bidding	and	Tenders     Cost	Management   * * Contract	Management  Generating	Reports       Project	Dashboards       Stakeholder	Management *O	&	M	Manuals  CollaborationEmployee	Messaging  Facilitates	Discussion	 User	Generated	Content        Sharing	of	content        User	GroupsUser	Identification/TaggingScreen	SharingWhiteboard	CollaborationVideo	ConferencingUser	Notifications        Unique	FeaturesIntegration	with	existing	systems *  *Customized	workflows	and	Forms  *   Customized	sharing	settings       Offline	Access       *Ability	to	store,	upload	and	attach	Photos         BIM	Support   Augmented	RealitySearch	Capabilites         Site	WearablesVoice	Recognition	 QR	Code	ScanningSuported	PlatformsiOS         Android         Desktop         Cloud	Based	         Construction	Management	Software	Comaprison*Limited	Capability21 Some reports related to the use of construction software were also reviewed. A survey conducted amongst industry professionals in the US (approximately 2000 respondents), by JBKnowledge in 2015, revealed that over 80% of companies are providing both laptops and smartphones to employees. iOS is the most common operating system in use, followed by Android and then Windows. A similar trend is observed amongst the popular construction applications available in market. The report also shows that field data collection and project management solutions are most likely to have full mobile capabilities (JBKnowledge 2015). The commonly used methods for project management and for collecting data on the field, as per the report are shown in Figures 2.1 and 2.2 respectively.   Figure 2.1 Commonly Used Methods for Project Management (Source: JBKnowledge (2015)) 22  Figure 2.2 Commonly Used Methods for Data Collection on Field (Source: JBKnowledge (2015)) Some of the commonly used field data collection software, as per the report, include AutoDesk BIM 360, HCSS, Procore, and Viewpoint. A few participants in the survey pointed out they are “struggling to find the right solution”, issues related to budget, connectivity, learning curve and training with respect to field data collection software. Furthermore, a report by McGraw Hill mentions that there is no single application in the market that meets all the contractor needs (McGraw Hill Construction 2013).  Armstrong (2015) also points out that the majority of applications in the market are point solutions and not integrated with one another. These issues again stress on the importance of finding the right requirements for the construction software to be used within an organization.  2.2.3 Collaboration Technologies in Construction Collaborative learning is being increasingly seen as a way forward in the industry to improve the project delivery and help organizations in future projects (Tan et al. 2010). In order to remain competitive and productive in today’s market, the construction industry needs to start embracing a collaborative approach towards executing projects.  23 Shelbourn et al. (2007) point out that collaboration eliminates fragmentation, duplication, and distrust. They further point out that for a team to effectively collaborate, a balance of three key strategies is required: business, people, and technology. The six critical aspects of each of these strategies are: vision, stakeholder engagement, trust, communication, process, and agreement on technologies. All of these six factors need to be addressed in the three strategic areas (i.e. business, people, and technology) to ensure effective collaboration in any organization or project.  Wilkinson (2005) defines a construction collaboration technology as “a single shared interface between two or more interested individuals (people), enabling them to participate in a creative process undertaken by two or more interested individuals, sharing their collective skills, expertise, understanding and knowledge (information) in an atmosphere of openness, honesty, trust, and mutual respect, to jointly deliver the best solution that meets their common goal(s), while simultaneously creating an auditable electronic record of people, processes, and information employed in the delivery of the solution(s)”. He further highlights that successful collaboration is more dependent on the culture of the team, i.e. people and processes, rather than the technology they employ. There is approximately an 80/20 split between these two factors. A collaboration platform allows employees to connect with colleagues, discover new people, accelerate teamwork, and share their expertise in an organizational setting. Many industries such as automobile, manufacturing, IT and banking are using social collaboration software to improve processes, products services, and also to provide an environment for innovation. The construction industry, on the other hand, is lagging behind. The temporary nature of construction projects, resistance to change, dynamic project environment, and heavy fragmentation makes it a complex industry to apply such collaboration technologies.  24 Wilkinson (2005) reviewed leading construction collaboration technologies available to users. He then developed a list of core requirements and functionalities for a collaboration technology:  • Organization Features: Security, User Directory, Information Administration • Communication Features: File Publication & management, Feedback • Management Features: Workflow management, Team Management • Sharing, viewing and working with CAD drawings • Ease of use  • Support Services He also identified key innovation areas which can have a future impact on the construction technology market which include: real-time collaboration, Building Information Modelling (BIM), Mobile Connectivity, Interoperability and Radio Frequency Identification (RFID).  Some of the popular social collaboration platforms currently being used in different industries were also reviewed for this research. These collaboration platforms can be potentially used for knowledge management and information sharing in an organization. The objective behind the review was to understand the existing features and functionalities of these platforms. The review is based on the publicly available information on the websites of the software providers, and in some cases, through the author’s own experience gained by using the trial versions. Some of their key features and functionalities are shown in the Table 2.3.  25 Table 2.3 Social Collaboration Platforms Name Key Features Platforms Industry Jive-n (Jive 2015) Discussion Groups, Blogging, File Sharing, Messaging, Employee Directory, Smart search Integrations with emails, MS office, storage repositories and real-time communication software’s Desktop and Mobile Telecom, Financial Services, IT, Healthcare, Media, Energy and Sales, Hospitality Yammer (Microsoft 2015) Collaboration Groups, Messaging, Microblogging, Tagging, Document Collaboration, Social Graphs, Search and Intelligent Feed, Integration with SharePoint  Desktop and Mobile Automobile, Airline, Education, Professional Services Banking, IT, Financial Services IBM Connections V5.5(IBM 2015) Activity Streams, Wikis, File Management, Task Management, Microblogging, Tagging, Multimedia Sharing, Search, Ideation, Communities and Social Analytics. Integrates with MS Office, IBM Notes SharePoint Desktop and Mobile Manufacturing, Banking, Retail  26 Name Key Features Platforms Industry Sitrion ONE (formerly newsgator) (Sitrion 2015) NewsFeed, Microblogging, Tagging, Multimedia Sharing, Ideation campaigns, Approvals, Engagement Analytics. Integrates with SAP, salesforce and SharePoint Desktop and Mobile  Automobile, Pharmaceutical, Healthcare, Consulting, Insurance, CPG, Banking, IT,   SharePoint (Microsoft 2016) NewsFeed, Microblogging, Messaging, Tagging, Smart Search, Following, Integration with Outlook, Document Collaboration, Communities, Personal Sites,  Workflow Management,  Integrations with other social applications such as Yammer and Sitrion Desktop and Mobile Automobile, Manufacturing, Education, Construction*  2.3 Information Technology (IT) in the Case Organization  This section starts with introducing the current state of digital maturity of the organization. It briefly present a few examples of software (internally developed and external) being used in Engineering Services. This is followed by presenting the existing process of software development within the organization. A more detailed description of existing software usage in the Underground 27 Utilities (Water and Sewers) and Project Management branches within Engineering Services is provided in Chapter 4.  2.3.1 Organizational Context of IT The Digital Strategy and IT groups in the organization are aimed at enhancing multidirectional connections amongst citizens, employees, business, and government. The Digital Strategy group was formed in 2013. Both these groups work in liaison to provide digital solutions for various departments in the organization.  The public sector case organization underwent an assessment by a consulting company with regards to their digital readiness. The capability areas assessed included online, mobile, social, infrastructure and assets, and organizations measured across four levels of maturity (absent, exploring, enabled and connected). The assessment revealed that the organization is currently exploring the use of social, online and mobile tools i.e. they have the basics and they realize that with the right technology they can perform better. This was followed by the Digital Strategy group outlining the following key objectives with respect to their organizational digital maturity goal: 1. Establish digital governance to define services and accountabilities 2. Optimize the use of technology to enhance productivity and metrics based decision-making 3. Develop a culture that empowers organization staff to innovate with digital technologies One of their priority initiatives is to implement a mobile workforce strategy. The organization has been successful in deploying some public facing mobile applications and were developed by third party vendors. Some of the key requirements for these applications were usability, quality of features, user-intuitive design, and ability to add-on functionality to these applications in the future. One of these mobile application had the core requirement of having the 28 ability to submit service request and enabling citizens to report any issue at any time by simply using their smart phones. The Digital Strategy Group has also built other functionalities such as information regarding recreation facilities, garbage collection schedules, and news related to the organization. They have also linked this service request application to the Twitter and Facebook pages of the organization. More recently, the digital strategy group has been working with the branches within Engineering Services to make use of this application internally as a staff reporting tool. Some consideration has been given to use this application as a tool for reporting other paper-based processes such as building damage assessment.  Within the Underground Utilities and Project Management branches, there is interest in looking at other potential construction software and technologies which can improve productivity, decision making and facilitate collaboration.  The existing software in these branches are described in Chapter 4. Within the PMO, there has been interest in using a suite of Microsoft Productivity Solutions including SharePoint, Enterprise Social, and OneDrive for sharing information across teams, enhancing productivity, and managing project portfolios. The current challenge is lack of sufficient clarity on their internal requirements before adopting a software solution. The PMO recently developed an intranet website by working with the IT and the digital strategy group. The website allows the PMO to facilitate implementation and training of project management frameworks within the organization. The website was developed through continuous feedback from the project team to determine the look and feel, and its various functionalities.  Some other applications such as TrackIt (for safety management), PlanIt (for coordinating construction jobs), and Road Ahead (for providing information on road closures and events to public) have also been developed internally for Engineering Services through collaboration with IT and Digital Strategy group.  29 2.3.2 Existing Software Development Process Every branch within the organization has an IT Business Relationship Manager (BRM) who has a few business analysts (BA) in their team. These BRM managers act as a liaison between the business and IT. Typically, the business goes to the BRM to discuss the existing problems. The BRM works with the team of BA’s to scope the solution and then works with IT to build the solution. The structure of development and implementation team of any software, after the business case for the software has been approved, within the organization is shown in Figure 2.3. Project SponsorSteering Committee Project Manager IT Branch Business Relationship Manager’s Team Business Units Quality Assurance Team Change ManagersFigure 2.3 Software Development and Implementation Team Structure The steering committee is composed of key decision makers from the branches for which the software is being developed. These typically include the branch head, managers or deputy managers. The BRMs team is composed of Business Analysts, who work with the business units to understand the existing business and define product requirements. A product owner is assigned who can make decisions on behalf of all the branches involved, and works directly with the IT branch in the software development phase. This is done to avoid conflicting opinions and preferences from different stakeholders. The Business Units consists of subject matter experts from each branch; there is usually one person representing each branch.  The quality assurance team is 30 composed of developers, process managers, and daily users of software to perform systems and user acceptance testing of the product. The change managers are responsible for integration of the software into the business through managing stakeholder expectations and assessment of the software developed by IT.  Discovery PhaseDevelopment/Procurement PhaseImplementation and Release PhaseTransition to Operations Figure 2.4 Software Development and Implementation Process The process for software development and implementation is shown in Figure 2.4. The high level software requirements are completed in the discovery phase through holding stakeholder workshops. The current practice is to use user stories to capture requirements; the IT department finds that this is the best way of capturing stakeholders’ needs within this organization. This is followed by either an external procurement of the software or in-house development. The IT and Digital Strategy departments prefer to adopt and implement external software services within the organization since it makes the management and support easier. They are open to changing their existing processes to match them with the processes of the software. In case of in-house 31 development, the implementation is divided into different phases. Each phase delivers a workable software product for the business. The existing practice within the organization is to follow an agile development methodology. Finally, in the transition period support is offered by IT to the branches to ensure complete integration and use of software by employees  In this research, the author takes the approach of a Business Analyst and investigates the current processes within the Underground Utilities (Waters and Sewers) and Project Management branches. 2.4 Understanding the Requirements Capture Process In this section, various software development approaches are briefly explained. This is followed by an in-depth review of a requirements capture process that was used to define a structured methodology for this research.  2.4.1 Introduction There are several methodologies which exist in software engineering to develop software. Some common ones include the waterfall, iterative spiral, and agile software development models.  The waterfall model follows a sequential development approach. The phases start with development of requirements through to analysis, design, coding, testing, and finally deployment and operation. The spiral model considers the iterative nature of design and development. Boehm (1986) described the model as “a risk driven approach to software process, rather than a strictly specification-driven or prototype driven process”. In each spiral of development, a new prototype is delivered which is then reviewed by the users. Once an accepted design is reached, the next steps consists of waterfall development starting from coding, testing, and then final operation and maintenance. The agile software model is a lightweight approach, which follows a people centered 32 approach based on collaboration. The requirements and solutions evolve, and adapt to the situations as the conditions change over time. This approach focuses on rapid development and releases of functional prototypes of software. Each release has new functionality added on top of the existing one.  Requirements discovery is a necessary forerunner in any of the software development methodologies. Requirements are the description of the needs and desires for a system or application, and define the function of the system and its components.  It is critical to capture requirements accurately to ensure that the right product is being built. There are several trawling techniques used—such as apprenticing, mind mapping, user stories, scenarios, and use case workshop—to understand the current nature of work and discover the requirements.  2.4.2 Volere Requirements Process In their book, Robertson and Robertson (2013) describe the Volere Requirements Process, as shown in Figure 2.5. They stress the importance of requirements to build the right product and the need to follow an orderly process to capture them. This process has been used for developing products using several iterative and sequential software development methodologies such as spiral, scrum, incremental, waterfall. It can also be modified for applying on custom developed processes.  The process starts from a project blast-off where the owners define the scope of business problem and identifies the area which need to be improved. This is followed by the identification of the stakeholders, i.e. the people who have interest in the product or who have knowledge pertaining to the product. At the end of the blast-off phase, the project goals, costs and risks are defined.  33 The next step is to start investigating the work. The key element in this phase is to understand and record the current work processes from the view point of the stakeholders. It is also important to understand the aspirations of the stakeholders for the work they hope to do in the future. There are several trawling techniques one can use in this phase—such as apprenticing, scenarios, use case workshops, and interviewing—to study the business areas. The technique to use is determined by considering the situation and choosing the one which proves to be most    Figure 2.5 The Volere Requirements Process ( Source: Robertson and Robertson (2013)) advantageous. It should take into account the stakeholders, culture of the organization and availability of resources. One may also use a combination of techniques for their investigation. 34 When investigating a work area, there are four critical viewpoints that one needs to consider. They are represented using the Brown Cow model as shown in Figure 2.6. This model is useful in defining the structure and type of questions for investigating the work. This thesis makes extensive use of this model for designing interview questions (for data collection) and analyzing the data.  Figure 2.6 The Brown Cow Model (Source: Robertson and Robertson 2013) The four viewpoints of this model are briefly explained below:  How-Now: This is a view of the work as it currently exists; including the physical artefacts, people and machines used to do work. It is captured through business use case scenarios or process models What-Now: This is the view that represents the essence of the work. This view is completely technologically neutral; shows the business as if no machines, people or organizational departments exist.  Future-What: This view shows the work as the owner wants to have it. It is the purest version of future work without using any technology, artefacts or people.  35 Future-How:  This view augments the future-what work view with technology, people, and artefacts to arrive at product use cases scenarios. The envisioned future product use case scenarios are derived from the existing business use case scenarios. They represent the extent of work that will be done using the software. Both the business and product use cases are discussed with stakeholders until a mutual consensus is reached. When designing the product use case, one must consider factors such as user experience, innovation, costs, constraints, non-functional and functional requirements, organizational goals, differentiation and technological possibilities. When discovering the requirements, quick and dirty prototypes are often used to present the simulation of the requirements to the users. The next step in the Volere Requirements Process is the transition from the product use case scenarios to define the requirements for the software. The requirements should include a description, a rationale and a fit criterion to ensure each requirement is measurable and testable. The functional requirements can be written either in an atomic form, in the form of user stories, scenarios, or business process models. The choice depends on the development method, stakeholders and organizational culture.  Once the requirements are written, they are checked for completeness, relevance, testability, consistency, correctness, ambiguity, and viability before being sent to developers. This can be done through self-verification, peer reviews, or review by team of testers and stakeholders.  2.5 Conclusion This chapter provided an overview of the different areas of research in the field of mobile computing, showcased the features of some commercially available construction software and collaboration platforms. The summary points of topics discussed in this chapter is presented below:   36 1. Benefits and challenges of using mobile IT in construction, as identified in the literature (Bowden et al. 2006; COMIT 2005; McGraw Hill Construction 2013; Olofsson and Emborg 2004; Saidi et al. 2002).  2. The development of frameworks and systems related to mobile computing, as described by other researchers (Ahsan et al. 2007; Chen and Kamara 2011; Kim et al. 2013; Venkatraman and Yoong 2009). 3. Availability and use of construction software that is increasingly available and in use  by organizations (JBKnowledge 2015; also refer Table 2.1 and 2.2) 4. Collaboration platforms that can be potentially used for knowledge management and information sharing in construction organizations.  There is limited research in areas related to defining software requirements, or on methods to choose the correct software for a construction organization. While some researchers (Ahsan et al. 2007; Kim et al. 2013) specify the requirements for their models, they do not explicitly define the process behind capturing these requirements. There is also a need to incorporate additional features in software which can result in collaboration amongst employees to facilitate knowledge and information sharing.   Currently, there are several commercially available solutions available both for project management and collaboration. However, one challenge for the construction organizations is to identify their business needs and select or develop software that can be easily implemented and integrated with their internal processes. The other challenge is getting buy in from their employees to use a new software. This thesis aims to shed some light on the process behind capturing requirements by using a case study of a particular construction organization. Since the 37 requirements vary from one organization to another, it is difficult to define a set of requirements, which suits the needs of all construction organizations.  The Volere Requirements process described in section 2.4 will be used as a guideline in defining the methodology for this research. Some of the steps in the process have been modified to suit the needs of the case organization. This thesis builds on the past work done, highlighted in this chapter, and will make an attempt to illustrate a requirements process.  38 Chapter 3: Preliminary Investigation: A Case Study of Software Implementation on AYO Smart Home Project 3.1 Introduction Before investigating the work at the case organization, a preliminary investigation of software implementation for a knowledge management process of a construction organization, called AYO smart home, was carried out. The goal behind this preliminary investigation was to refine the research methodology for this thesis; and develop a better understanding of the requirements and mindset of construction industry with respect to the use of software on a day-to-day basis. In this investigation, a collaboration platform was tested during the construction of a high-performance, low-cost prototype house called the AYO Smart Home. The associated challenges and successes during its implementation were documented.  This chapter first introduces the topic of knowledge management and social media platforms in construction. Then a use case of the SocioBIM application and a brief overview of the Green 2.0 system is presented. The next section describes the background of the AYO Smart Homes Project, the implementation methodology, and a post implementation review. The chapter concludes by describing the key learnings from this preliminary investigation.   This chapter has been published in the proceedings of the International Conference on Sustainable Design, Engineering and Construction in Tempe Arizona, 2016.  3.2 Knowledge Management in Construction Knowledge is one of an organization’s most important assets, hence organizations should strive to capture and reuse the knowledge of their workers in order to have continuous improvements. Knowledge management is the process of capturing, developing, sharing, and 39 effectively using organizational knowledge. Knowledge in an organization can be broadly classified into two categories: explicit and tacit knowledge. Explicit knowledge is that which can be measured, captured, examined, and easily passed onto others in a codified format–a formal and systematic language. Tacit knowledge, on the other hand, is highly personal, context-specific and comes from one’s experience. It is hard to measure, capture or examine. Construction is a project-based industry where the project team comes together to work on a project and often disintegrates at its termination. The dynamic nature of the industry results in new learning every day related to issues and successes on the construction site but often these are not captured, resulting in a state of “reinventing the wheel” when a similar issue arises in the future. The common practice in the industry to capture lessons learnt is through project reviews that happen at the end of project (if at all). However, these reviews often happen very late after the end of the project when most of the team have moved on to other projects, and typically not enough importance is given to these reviews by team members. Hence, they end up being a mere formality and do not capture the tacit knowledge of individuals (Newell et al. 2004). There are various techniques and tools available for knowledge management. Some common techniques include brainstorming, communities of practice, face-to-face interactions, post-project reviews, mentoring and apprenticeship. The tools which can facilitate knowledge management include, but are not limited to, groupware, intranets, knowledge bases, instant messaging, and data/text mining technologies (Al-Ghassani et al. 2005).  Building Information Modeling (BIM) is a technology that has caused a paradigm shift in the Architecture, Engineering and Construction (AEC) industry; it has transformed the way buildings are designed, constructed and managed. BIM is moving the construction process from “lonely” to “social” data, in the sense that BIM is enabling professionals: designers, constructors 40 and building managers to easily share information with each other. SocioBIM applications (introduced in (Grover et al. 2015) and (Shoolestani et al. 2015)) are defined as a combination of BIM and social networking to produce socio-technical systems, particularly related to BIM applications that involve the public or end users (e.g., building occupants). In the introductory papers relating to SocioBIM applications, Grover et al. (2015) and Shoolestani et al. (2015) focus primarily on applications during the pre-construction and post-construction phases. However, another potential area for SocioBIM applications is the phase during construction, which deals with two way interactions between building professionals relating to issues such as constructability, productivity, site safety, lessons learnt, quality issues etc. This preliminary investigation is based on the hypothesis that the use of a BIM-based social platform in the construction phase for knowledge management can result in effective capture and reuse of tacit knowledge. This chapter describes the implementation of a SocioBIM application called the Green 2.0 system (described in the later sections of the chapter) on the AYO Smart Home Project. This project was being built on The University of British Columbia campus in Fall 2015.  3.3 Social Media Platforms for Knowledge Management in Construction Social media platforms are an invention of the 21st century that have diverse applications from developing personal or professional networks, marketing, news dissemination, customer feedback etc.  The building blocks of a social media platform, as defined in the framework proposed by Kietzmann et al. (2011), include: identity, presence, relationships, reputation, groups, conversations, and sharing. It is not necessary that all social media platforms have all these elements; there may be cases where the focus is just on a few of these blocks. Web 2.0 technologies such as wikis, blogs, web-based forums, and social networks have been implemented by many organizations to capture and share knowledge. Some of the benefits of Web 2.0 over traditional 41 knowledge-management technologies include its ease of use, search capabilities, open-source availability and, most importantly, its potential to re-create a virtual social environment by promoting discussions (McAfee 2006). Such social platforms have the potential of capturing both the tacit and explicit knowledge that is generated every day in projects and sharing them among different stakeholders, ultimately resulting in cross-project learning. Past research suggests that a community model or a personalization strategy is better than a database approach (Anumba et al. 2003; Hansen et al. 1999; Keegan and Turner 2001; Swan et al. 1999). Panahi et al. (2013) argue that the use of social web tools can be regarded as complementary to facilitate tacit knowledge capture and sharing. Wahlroos (2010) identified some of the main factors that impact employee’s knowledge sharing behavior on social media platforms, which include personal (benefits, experience with social media), organizational (managers’ & colleagues’ activity, guidelines, collaboration features) and technological (user-friendliness and skills required) .Vuori and Okkonen (2012) found that the main motivators for employees are desire to reach the organizational goals, help colleagues, and receive knowledge in return, all intrinsic benefits. Extrinsic factors, such as financial rewards or promotion opportunities, were the least motivating factors. The main barriers impeding knowledge sharing through the social platform were found to be fear of the additional time and effort required, the concern that it may be just another un-used information system, and the expectation of not receiving significant knowledge in return. According Panahi et al. (2012), some important requirements in a social platform that can facilitate tacit knowledge include: social interaction, experience sharing, observation, informal relationships/networking, and mutual trust. The use of social collaboration platforms such as SharePoint, IBM Connections, Confluence etc. for knowledge capture and sharing has become quite prevalent in other industries 42 such as automotive, manufacturing, IT, and oil and gas.  However, the temporary nature of construction projects, resistance to change, and heavy fragmentation makes it a challenging industry to apply such platforms. Furthermore, historically the construction industry has been slow in adopting ICT developments. The industry does a good job in capturing the explicit knowledge generated on the projects, but has not developed systems to capture tacit knowledge. Newell et al. (2004) critique the current way of knowledge sharing in the construction industry and use a case study approach to conclude that placing effort on developing personal networks can be more effective than using databases to capture knowledge. Dave and Koskela (2009) used a case study approach to test a social platform, based on Internet forums, in a construction company. The platform enabled an active exchange of knowledge, had high user participation, and the knowledge generated was directly applied in the workplace. Their work also highlights some of the challenges associated with implementing a platform for tacit knowledge capture such as ease of use, trust amongst employees, importance of knowledge sharing in organization, and involvement of top management. In their paper, Tan et al. (2007) highlight the requirements for the live capture and reuse of project knowledge: accuracy of knowledge captured, facilitation of knowledge capture and reuse, and avoidance of legal issues, additional cost or workload for workers. They propose a methodology for live capture and reuse of knowledge comprising of a web-based knowledge base, a project knowledge manager and an integrated work-flow system. Kivrak et al. (2008) built on their framework to propose a Knowledge Platform for Contractors (KPfC). Some potential benefits of this system have been proposed (without any empirical evidence): reduction in rework, sharing and retaining of tacit knowledge, innovation encouragement, continuous improvement, client satisfaction, and organizational learning. Ferrada et al. (2014) proposed a mobile lesson-learned system application which allows creating, allowing, evaluating, and searching lessons learnt inside 43 the database. The users also have an option of posting a microblogs, similar to twitter, and directing it to a particular person or a group of people. The lessons learnt are collected in a structured format where user were asked to enter fields such as title of lesson, description, creation date, classification, and name of lessons approver.  Most of these aforementioned papers point out that there is a lack of empirical evidence to support the benefits of social media platforms for knowledge capture in construction. The next sections describe the use case for the SocioBIM application and the Green 2.0 platform 3.4 SocioBIM Application for Knowledge Management 3.4.1 Use Case The main requirement of design is to provide a rich social experience where knowledge exchange happens in an open and informal way. In the use case shown in Figure 3.1, the building industry provider, which includes architects, contractors, site foremen, superintendents, workers, project managers etc., are able to walk through the BIM model of the facility. They can post comments regarding any issues related to constructability, quality, safety, clashes, or any other lessons learned related to a particular building element. They have the option of attaching pictures, writing microblogs, and tagging their colleagues or sharing their posts with a specific group of industry providers. The other users are then able to view these issues and engage in a social discussion on them resulting in collaborative decision making. The users are also given an option to provide a numerical rating to the postings by other users, which can establish a reputation of various users and get expert opinions on feasibility of solutions to issues. This process has the potential of enabling a continuous capture of knowledge coming from different stakeholders, especially the tacit knowledge being generated on-site every day. 44  Figure 3.1 Use Case for SocioBIM Platform 3.4.2 Green 2.0 Platform The Green 2.0 project (CANARIE 2015), which undertook to develop a middleware platform for enabling socio-technical analytics of green buildings, was a collaborative research project led by the University of Toronto. The project aimed at developing a web-based middleware platform to empower professionals from diverse background to create analysis applications while engaging public users’ ideas. The platform brings together several core enabling technologies: open BIM for modeling buildings and related project information; social networks and social network analytics for supporting user interactions and investigating the results of this social interaction; energy analysis to model and provide feedback about the impact of various design alternatives; and business process modelling to model public users’ activities. The Green 2.0 45 platform is open source and free to use for both building professionals and public users. The original intent of the platform is “to make homes and buildings more energy efficient by allowing designers to educate themselves on the preferences of the people who will live and use their buildings, and by allowing the same people to be engaged in the decision-making process that will directly impact their lives” (CANARIE 2015). Our research group at the University of British Columbia was also involved in the project and was tasked with exploring potential applications of the platform. In this investigation, another potential application of this platform focused on Knowledge Management in the construction phase is being explored.  The Green 2.0 platform does not meet all the functionality requirements for the SocioBIM knowledge management application described in sub-section 3.4.1, but it has the potential to act as a useful tool to demonstrate the proof-of-concept of the use case shown in Fig. 3.1. It is a cloud-based platform, allows users to walk through a BIM model, comment on particular elements, categorize their comments, and reply to comments by others. Commercially available software’s like AutoDesk BIM 360 (AutoDesk 2016) exist which provide better functionalities in comparison to Green 2.0 platform but the objective of this study is not to propose a new software; rather, the interest is in analyzing the impact on knowledge management in the construction phase of the project by using a SocioBIM platform. Hence, Green 2.0 platform was selected as an appropriate platform to implement and test on a live construction project.  3.5 Case Study 3.5.1 Organizational Context AYO Smart Home is a company based in Vancouver, Canada founded in 2015. Their goal is to provide First Nation communities and other markets with affordable, durable, and culturally appropriate housing, while maintaining high levels of livability and energy efficiency. To help 46 reach this goal, they have built a pilot home on the UBC campus to use as a research platform to optimize the construction of future homes. The design was finalized in August 2015 after several consultations with the members of the First Nations community.  The construction started in Sept. 2015 and achieved substantial completion by January 2016. The two story, 1620 sq. ft. demonstration home has a Magnesium Oxide (MgO) Structural Insulated Panel (SIP).  In addition to the high-performance SIP panel envelope, the home makes use of innovative mechanical and lighting systems while adopting a passive design approach to maximize solar energy (AYO Smart Home 2015). This project was appropriate for implementation of the SocioBIM platform since it adopted a new approach to constructing houses with ambitious goals of achieving low cost and high energy efficiency targets. It was anticipated that the pilot home would face several challenges during the construction that would result in knowledge creation, both explicit and tacit, on a daily basis. If this knowledge was captured, it could potentially be reused in future projects, improving the overall efficiency and creating a useful knowledge base for future project teams. 3.5.2 Design and Implementation of Experiment Installing the pre-fabricated SIP panels was selected as an appropriate activity for implementing the platform. The installation lasted for approximately 14 days. The challenges, issues or successes relating to productivity and site safety were documented on a daily basis through conducting semi-structured interviews with stakeholders, recording time lapse videos, and on-site observations. A total of five members from the project team were interviewed: Project Manager, Architect, Site Superintendent, Structural Engineer, and Panel Installer.  An experiment was established to simulate the use of the prototype system on a daily basis by these central project participants (since it was not possible to impose the system on the actual 47 participants in real time during construction).  Once the panel installation was complete, five research participants (graduate students at UBC who were also involved in studying the construction phase of this project and were therefore very familiar with the details of the construction operation) were assigned one of the 5 aforementioned roles. They were introduced to the Green 2.0 platform and its various functionalities. Each participant was asked to register on the system. The architectural BIM model of the project was uploaded on the system (using IFC format) and shared with the participants. The participants were then directed by the platform administrators to walk through the BIM model and discuss the various issues related to specific elements on the platform. This exercise lasted for 14 days, the same duration as the installation of the panels. On each day of this exercise, the participants were shown the recorded time-lapse video of panel installation on the actual day of construction. They were also orally briefed on what activities took place on-site and what challenges and successes happened on the actual day of construction.  An example of the user interface of the platform is shown in Figure 3.2.  3.5.3 Post-Implementation Review A total of 44 comments were created by the participants, and 24 of these were replies to other comments. The system then mapped the social networks related to collaboration at two different levels–the project level and the building-element level. These are shown in Figure 3.3. Each node represents a unique user; the size of node represents the number of comments created by that user on a particular element or project. The edges represent, at the element level, co-commenting by different users on the same element and, at the project level, users who have co-commented on at least one element. The weight of an edge is proportional to the number of elements shared between two different users for commenting. It is difficult to explicitly evaluate the success of a SocioBIM platform by using it in only one project. The sizeable benefits can only 48 be realized when the platform is used for a longer time and across different projects to enable reuse of the knowledge being captured and better decision making. However, a few observations regarding the use of the platform can be made: • The element graphs were useful in identifying the specific building components on which the most or least discussions happened. This can be useful in future designs, scheduling, fabricating etc.  For example, in the case of the SIP panels, one of the discussions was focused on grouping the same panel shapes together by the use of numbers to reduce installation time, and there was a consensus amongst the four participants involved.  • The 3D BIM model in the platform made the discussions more holistic and engaging as the visualization made it easy to identify conflicts between different building elements and to anticipate future risks related to delays, safety, or other issues.  For example, one discussion highlighted that the installation of the front posts and the roof could have been accelerated if certain modifications were made on the concrete footing in advance. • The size of the nodes was useful in identifying the most active participants in the discussions and, since each participant has their own profile, different kinds of analytics on this information could provide insights about the social construct of the discussions  • The problem solving followed a collaborative approach and there was continuous feedback from different participants. This can ultimately result in creating a continuously evolving knowledge base of best practices that can be used in future projects   49  Figure 3.2 Green 2.0 Platform for Knowledge Management  Figure 3.3 Social Networks of Participants at Project and Element Level  50 In addition to these observations, some of key recommendations were made by the participants to improve the platform functionality and to make it more engaging for users: • Have the option of tagging different participants, quoting comments from others, and rating the solutions of others. • Add an ability to select multiple building elements at once to assign group comments. • Include an ability to search for keywords within the comments. • Add multimedia content to the comments. • Provide a structured format for comments. 3.6 Conclusion  This chapter discussed the current issues with the construction industry related to the capture and reuse of knowledge, in particular the tacit knowledge. The various benefits and challenges were highlighted through a review of past research done on using social platforms for knowledge management in construction. The demonstration of a social BIM platform, referred to as a SocioBIM application, for knowledge construction in construction was presented. The limitations and benefits of using such a platform have also been discussed based on post-implementation reviews and feedback from participants. The platform serves as a proof-of-concept for the idea of using BIM-based social platforms for knowledge capture and adds another case in the limited pool of case studies related to innovative approaches for knowledge management in construction. The idea of the SocioBIM effectiveness can be further supported by future applications in subsequent projects.  More research and case studies are needed to further assess the usability of such platforms.  51 This preliminary study further reinforces the importance of carrying out a stakeholder engagement process before adopting any construction software. This was useful in refining the methodology and adopting a bottom-up approach. In this study, the software was pushed down to the organization without carrying out any requirements process. The expectations of the stakeholders were assumed, rather than pulling the requirements from them through carrying out an orderly requirements capture process. As a result, the software came across as an additional burden and did not end up being used by construction workers even though there was a push from top management. 52 Chapter 4: Organizational Review: Public Sector Construction Organization 4.1 Introduction This chapter first discusses the scope of the organizational review conducted. This is followed by a description of the organizational structure, existing technologies and software in use. The subsequent sections describe the approach used to identify the potential areas, within the branches, where construction software can be implemented. The chapter concludes by highlighting the identified areas for investigation.  4.2 Scope of Organizational Review The case organization has a mission to create a community that cares about the people, environment and opportunities to live, work and prosper. This research focusses on a few branches within the Engineering Services division. With an annual combined capital and operating budget of over $500 million, and 1800 employees, Engineering Services is responsible for the construction and maintenance of the organization’s public works infrastructure, including water supply, sewers, solid waste collection and landfill operation, streets and street lighting. Engineering Services is also mandated with planning and regulatory functions including transportation planning, traffic control, street use and parking by-law enforcement. The high level organizational chart for Engineering Services in shown in Figure 4.1. The scope of this research is limited to the following branches within Engineering Services (these branches have also been highlighted in Figure 4.1): 1. Underground Utility Design and Operations: are responsible for design, construction, inspection and maintenance of water and sewers systems.  2. Project Management Office (PMO): is responsible for proactively supporting delivery of excellence in project and program management with a focus on continual improvement. 53 General Manager Engineering ServiceWaste Management and Resource RecoveryStreets TransportationShared Departmental Services• Kent Construction and Supplies• Construction operations support and safety• Equipment Services• Team Services• Streets and Electrical Design• Streets, Traffic and Electrical Operations• Parking Operations and Enforcement• Solid Waste Strategic Services• Sanitation Operations• Transfer and Landfill Operations• Solid Waste Program ManagementUnderground Utility InfrastructureProject and Quality Management• Strategic Transportation Planning• Traffic and Data Management • Neighbourhood Parking and Transportation• Active Transportation• Film and Special Events• Waterworks Design• Waterworks Operations• Sewers and Drainage Design• Sewers and Drainage Design• Sewer Operations• Street Activities• Utilities Management• Land Survey Services• Project Management • Project Delivery• Projects and Development Services for third party  Figure 4.1 Organizational Chart: Engineering Service (As of December 2015) 54 4.3 Existing Structure and Technologies in Underground Utility and Project Management Branches The Underground Utility (Waters and Sewers) branch is responsible for design, construction and maintenance of underground utilities in the organization. It has its own internal workforce, which is responsible for doing design and construction of all small and major construction jobs across the organization. The work is contracted out to third parties only when there is limited in-house capacity to perform a job; for example, if trenchless sewer construction is required at an intersection. The construction material comes from various sources. Some of it, such as asphalt and recycled backfill, is produced internally at the organization-owned work yards. Other materials, such as pipes, valves, fittings, concrete, aggregate etc., is procured locally or internationally. The organization owns most of its construction equipment but does lease some equipment on a daily needs basis.  The Project Management Office (PMO) is responsible for introducing and developing standard templates, processes, and guidelines for managing the capital infrastructure projects in Engineering Services. It also works with the Project Delivery Office to implement these project management frameworks on the departments capital projects.  Currently, the means of communication between these branches, the site, and the office is mostly through emails, paper-based documents, messaging, and phone calls. Most of the current processes on-site—such as site inspections, reporting timesheets, capturing lessons learnt, safety reporting, daily logs—are paper based.  The organization uses a document management software for sharing and archiving documents. Employees are able to edit, download, and search for documents. Employees have their own desktop or laptop, and some employees are also provided with mobile devices. All 55 desktop or laptop systems in the organization run on Windows, and the mobile devices are iOS. Internal communications are done through e-mails, calls, inter-office mail, or face-to-face conversations. Staff collaboration tools such as Cisco Jabber are used for Instant Messaging (IM), voice, video, desktop sharing, and conferencing. The organization uses SAP for managing all the financial data and Hansen for asset management. Some groups within the organization make use of SharePoint sites and wiki pages for internal collaboration, but these collaboration platforms are not being used cohesively across branches in Engineering Services. The Design Branch within Underground Utilities is responsible for design and makes use of AutoCAD for drafting.  A few internally developed software tools have been developed within the Engineering Services department to improve communication and planning for projects. PlanIt is being used for coordinating different construction jobs and events in the organization. Road Ahead is another one being used to provide information to the public regarding road closures and special events in the organization. TrackIt is being piloted in the Sewers division construction operations for safety management. It allows users to create custom forms, take pictures, and notes. An application for underground utilities map is another used by design and operations branches to determine the position of water, and sewer mains, property lines. They also use a public facing service request mobile application that allows the public to submit service requests, get updates, and information about the organization. The underground utility branch also makes use of web-based fluid surveys in addition to hard copies to get feedback from public The Project Management Office uses an intranet website, developed internally, to implement the Project Management framework and train their employees. The website has training sessions, tools and templates corresponding to each knowledge area. It also has a section to allow employees to give feedback on the frameworks. The PMO has also developed an Integrated Project 56 Management Tool (IPMT) through working with external consultants. It is an excel based tool and is used by Project Mangers to capture project information, budget, change log, risk register, stakeholder register, schedule, cash flow, stage gate checklists, and project reports.  4.4 Scoping the Research Problem 4.4.1 Graduate Internship with the Organization The case organization is actively working towards becoming internationally recognized for its green objectives. It has crafted an action plan for the goals that it has set to be met by 2020—including reducing greenhouse gas emissions, encouraging the growth of green jobs and businesses, requiring green construction, and reducing waste. As a graduate intern in the summer of 2015, the author was working with the Project Management Office. The main objective of the work was to identify opportunities to green the design and construction operations in underground utility and streets branches. The author conducted field observations and stakeholder interviews to benchmark existing green operations and identify opportunities for improvement. The author identified a total of 15 opportunities and provided recommendations for their implementation.  During the site observations and interviews, the author also observed some other issues such as heavy reliance on paper-based communication, limited sharing of knowledge within and across the different branches, inefficient internal communication processes, and inconsistence of document management software by employees. The author used this as a starting point to define the scope of work and started to conduct interviews with the relevant groups in the organization to explore the potential of using construction software in the organization to help resolve these issues.  57 4.4.2 Interviews with Project Management Office (PMO) and Digital Strategy Group In the beginning of the research, semi-structured interviews were conducted with the senior management of the PMO, Underground Utility and Digital Strategy branches. These interviews were in addition to the 30 stakeholder interviews and on-site observations of five different projects from the Underground Utility and Streets branches, which the author conducted during his graduate internship with the organization. The stakeholders for the semi-structured interviews were chosen from different branches having expertise in different areas within the organization to ensure that they provided a good representation of the work the organization performs. The objective of these semi-structured interviews was as follows: 1. Existing Needs: to identify a high-level list of pain areas within the organization which could potentially be addressed by the software.  2. Potential software users: to identify the audience for the use of the software within the organization 3. Potential business processes: to identify the potential business areas and the existing processes for integration with the software 4. Stakeholders: to identify employees who will be impacted by the use of the software, and will provide input in identifying its requirement 5. Communication with existing systems: to identify the software and systems which may communicate with the construction software being developed.  6. Constraints: to identify the perceived organizational, technological, and monetary constraints on the software  58 A mind map template developed by Hiranabe (2008) was used, which outlines the basic ordering ideas (i.e., the radial branches emerging from the center). This mind map is shown in Figure 4.2. It was used as a high level container having the various needs and expectations of stakeholders. 59  Figure 4.2 Construction Software Mind Map 60 4.5 Identified Areas for Investigation Construction software could be used to address a myriad of challenges and opportunities as identified in Figure 4.3. In order to narrow the scope of this thesis the mind mapping exercise was followed by reviewing the organizational goals and objectives, and connecting them with the potential areas for investigation. This resulted in identification of six business areas in which the author saw a potential for software use. These were also confirmed with a senior executive in the case organization responsible for improving efficiencies across various departments in Engineering Services.  1. Construction -related public communications: 2. Knowledge Management and Collaboration 3. Implementing Green Operations 4. Sharing Site Information 5. Implementing Project Management Framework 6. Daily Logging and transfer of construction data The categorization of the six identified areas as per the organizational and engineering services goals is shown in Figure 4.8. Each of the identified business area was further divided into business events, i.e., the activities to which it was related. The business events were investigated through stakeholder interviews to understand the existing processes and develop business use cases. These steps have been discussed in the next chapter.   61       Figure 4.3 Identified Business Areas for Investigation 62 Chapter 5: Data Collection 5.1 Introduction This chapter elaborates the data collection methodology and presents the data collected for analysis. The first section describes the business events related to the identified areas in Chapter 4. This is followed by a description of interview techniques and the business use cases (BUCs) corresponding to each business event. The chapter concludes by identifying the shortlisted BUCs, which will be explored for implementation by the software. 5.2 Business Events Business events are a breakdown of the activities that happen under a business area. They were used to partition the identified areas and study them thoroughly. The business events were discovered through using my own knowledge of the existing processes and through discussions with representatives from the different branches. The list of events, along with their corresponding business area, is shown below:  1. Construction-related communications with public. 1.1. Engineering Services wants to share information about upcoming construction with residents.  1.2. Residents want to provide feedback about the construction in their neighborhood. 1.3. Project team wants to know about the public feedback/KPIs related to it. 1.4. Project team wants to respond to public feedback/queries. 2. Knowledge management and collaboration. 2.1. Project team wants to know about the project status (schedule, costs, risks, green operations etc.) of other projects during planning or the execution of new projects. 63 2.2. Project team wants to capture lessons learnt or project-related new knowledge. 2.3. Project team wants to view captured lessons learned or project-related new knowledge. 3. Daily on-site logging and transfer of data. 3.1. Site foreman wants to report on the labor and equipment hours. 3.2. Site foreman wants to report on safety meetings, near misses and incidents on-site. 3.3. Site foreman wants to report on the daily expenditure. 3.4. Foreman wants to fill a Daily Hired-Equipment sheet. 3.5. Site staff wants to capture and store site photos. 3.6. Foreman requests third party documents5 before excavation. 3.7. Equipment dispatcher wants to prepare and report a Daily Location Sheet. 3.8. Project team wants to report on productivity, 311 calls, health and safety and quality of project weekly. 3.9. Equipment operator wants to prepare a vehicle inspection report.  3.10. Foreman wants to complete a sewer connection inspection report. 3.11. Superintendent wants to conduct monthly site inspections for operations. 3.12. Foreman wants to order/return materials from/to central stores. 4. Sharing project information between design and construction teams. 4.1. Project team wants to share design drawings with site personnel. 4.2. Project team wants to make design changes. 4.3. Design team wants to share schedule with operations.                                                 5 These are a set of drawings and permits from third-parties which have underground utility lines. The foreman is required to review them before starting any excavation.  64 4.4. Design team wants to conduct a conformance check. 4.5. Operations team want to create red-line drawings. 5. Implementing PMO framework. 5.1. PMO office wants to train employees the project management framework. 5.2. Project team has questions/feedback about the PMO framework.  6. Implementing Green Operations.  6.1. Sustainability office wants to share innovative methods or materials for greening construction operations with design and construction teams.  6.2. Sustainability office wants to communicate to crew regarding the goals and objectives of Green Operations as it relates to Engineering Services. 5.3 Stakeholder Interviews A BUC is a response to a business event. Each business event was investigated through conducting semi-structured interviews with stakeholders to document the related BUC. Semi-structured interview technique are used when the interviewer has a basic knowledge of the topic and needs to find more information (Willson 2013). Hence, they were selected as an appropriate technique for data collection. The interviews followed the framework of the Brown Cow Model, discussed in Chapter 2. The main objectives behind conducting the interviews were: • To observe and learn the work, and to understand it from the viewpoint of the owner, • To interpret the work and reveal its underlying essence, • To record the results in the form of a stakeholder-understandable language, • To identify the existing challenges with respect to the business processes. 65 The stakeholders, who were interviewed, from the different business areas in the organization were identified through discussions with the Deputy General Manager of Engineering Services. The interview questions were organized by business events. Context diagrams, artefacts, rough process models, and sketches were used to understand the work. During the interview, the stakeholders were encouraged to correct author’s sketches and process models. The author used active listening techniques, i.e. throughout the interview, the participant’s words were paraphrased by the author in a nonjudgmental way to the participant. This was done to verify the author’s interpretations of the work. Interview probes were used to trawl for knowledge. Each interview started with the explanation of the objectives of the study and with providing the interviewee details about the confidentiality, risks and associated benefits. User participation was voluntary and consent was taken to audio record the interview. On average, each interview lasted for about one hour. In the first round of interviews, which was focused on data collection, a total of 10 interviews were conducted. An example of the interview script for investigating the business area of construction related public communications, with the context diagrams, is shown below: 66  Figure 5.1 Work Context Diagram for Construction Related Public Communications Business Event 1.2: Residents want to provide feedback about the construction in their neighborhood. Q1. How do citizens provide feedback about the construction being done or completed in their neighborhood?  Q3. How does the organization keep a record of citizen feedback/complaints for each project?  Q4. What all things are they asked for in the survey? How is the survey administered?  Q5. Are there any other ways of getting citizen feedback?  Q6. If there was a new system that automates part of this work, ensures everything is stored in a central location, provides a digital method for citizens to provide feedback, and is accessible to different project teams, would that be useful?  The other interview questions related to other business areas and business events are shown in Appendix B. 67 5.4 Existing Business Use Cases BUCs are preplanned responses to a business event and are a unit of functionality of the business. Each BUC is isolated from each other and has continuous processing. There are no processing connections with other BUCs; the only overlap between BUCs is their stored data. (Robertson and Robertson 2013).  BUCs can be modeled and recorded using scenarios. A scenario is a sequence of steps that occur to complete the function of the BUC. The functionality of the BUC is broken down into steps, usually 3-10 steps. Each step should be a meaningful and recognizable activity which forms a part of BUC (Robertson and Robertson 2013). The template recommended by Robertson and Robertson (2013) was used in this research.  The BUCs for the corresponding business events listed in section 5.2 are shown below. Alphanumeric numbering has been used to list BUCs: for example, BUC 1.1, where BUC stands for Business Use Case and 1.1 is the corresponding business event. The BUCs presented below are arranged by the business areas under which they fall.  5.4.1 Construction-Related Public Communications  BUC 1.1: Sharing construction information with residents. Business Event: Engineering Services wants to share information about upcoming construction with residents. Trigger: A construction job/project is being planned for the near future. Interested Stakeholders: Community Liaison, Public Communications Group, Engineering Services, Project team, PMO Office. 68 Active Stakeholders: Community Liaison (CL), Communications Coordinator (CC). Process: 1. CC writes a notification letter (refer artefact No.1 Appendix A) with relevant project information. For Businesses • CL goes door-to-door to have a conversation and establish contact. • This is followed by a notification letter in their mailbox. For Residents. • The notification letter is sent by email. 2. During construction, if anything relevant issues arise, an ‘in-project letter’ is sent out to specific residents/businesses affected by it. Outcome: Construction information shared.69 BUC 1.2: Public feedback on construction. Business Event: Residents want to provide feedback about the construction in their neighborhood. Trigger: Residents wants more information/residents are experiencing issues with construction/project team needs the feedback. Interested Stakeholders: Community Liaison (CL), Public Communications Group, Engineering Services, Project team, PMO Office Active Stakeholders:  CL, Communications Coordinator (CC), Operations Group, Residents Process: Continuous Feedback 1. Residents can send personal letters, call 311, call the person in the notification letter (refer artefact No.1 in Appendix A), talk to the crew on site, send a letter to the senior executive, etc. 2. The project team member responds by phone, via email, or in person. 3. The communication via call is recorded on a communication log (refer artefact No. 3 in Appendix A) by the CC, CL or the person who gets the call. Surveys 1. At the end of the project, a person from the project operations group drops the surveys door-to-door. 2. The residents may fill the surveys online through fluid surveys (refer artefact No. 4 in Appendix A) or mail the dropped-off surveys back to the organization. 70 3. The mail-returned surveys are then entered onto a document manually. Outcome: Project team receives feedback. 71 BUC 1.3: View public feedback. Business Event: The project team wants to know about the public feedback/related KPIs. Trigger: Weekly meetings, Steering Committee meetings. Interested Stakeholders: Engineering Services, Project Team. Active Stakeholders: Foreman, Superintendent, Project Manager. Process: 1. Public feedback is discussed almost daily within the project team by foreman/superintendent on a case by case basis (i.e. not as an overall report). 2. Communication/Stakeholder updates are a regular part of weekly project meetings (case by case, both pro-active and reactive). 3. Project Manager discusses public feedback in steering committee meetings. 4. Superintendent or Project Manager also shares the public feedback with the project teams in project close-out meetings. Outcome: Project team is made aware of the project feedback. 72 BUC 1.4: Response to public feedback. Business Event: Project team wants to respond to public feedback. Trigger: Residents contacts the project team. Interested Stakeholders: Engineering Services, PMO Office, Organization Manager’s Office, Near Public (Businesses, Residents in proximity), Corporate Communications (CC), Site Superintendent, Foremen, Media, General Public. Active Stakeholders: 311, Project Team, Residents. Process: 1. Depending on how residents contact: a. Project Email Address. i. Someone replies. b. Smaller Projects (Level 1 and some of Level 2 projects). i. Emailed to specific person and the person responds back. ii. Call- have a conversation. iii. 311-basic info, forward to community liaison or program manager, if needed. c.  Social media (FB/Twitter) (only done for Level 2 and 3 type projects). i. 311 and CC Monitor accounts and reply right away with links. If they can’t answer, they assign it to communications. d.  Media (only done for level 2 and 3 type projects). i. Done through team at CC, spokes-people respond to media. Outcome: Response provided. 73 5.4.2 Knowledge Management and Collaboration BUC 2.1: Reporting and sharing project status. Business Event: Project team wants to know about the project status (schedule, costs, risks, green operations etc.) of other projects during planning or execution of new projects. Trigger: Done monthly. Interested Stakeholders: General Manager, Deputy GM, Branch Heads, Project Team, Communications team, Coordination Team. Active Stakeholders: Project Manager 1. Project manager fills the identification information for the project report (refer No. 5 in Appendix A)) and enters the name of employees between whom the report is to be distributed. 2. Project manager fills the project overview section by looking at information from the Project Execution Plan. 3. Project manager completes the progress since last report by referring to weekly construction reports, and discussing with project stakeholders. 4. Project manager fills in the key activities scheduled for the next month by looking at the updated project schedule. 5. Project manager reports on the status of scope, schedule, budget, change orders, health and safety issues, and risk by referring to Integrated Project Management Tool (IPMT) and construction reports (refer artefact No. 5 Appendix A for description of each sub-section). 6. Project manager attaches site photos to the report. 7. Project manager emails the report to the distribution list. 74 Outcome: Project status report shared.75 BUC 2.2: Capture lessons learned. Business Event: Project team wants to capture lessons learnt or project-related new knowledge. Trigger: A challenge/issue/problem/success is encountered on a project. Interested Stakeholders: Project Manager, PMO- Engineering Services, Operational groups (Superintendents, Foremen). Active Stakeholders:  Project Team (Project Manager, Design Engineers, Operations Superintendents). Process: 1. Lessons learnt are discussed weekly in construction site meetings. Aspects not covered in the planning stage or any new developments (good/bad) are considered across all project stages are distilled as lessons. 2. Initially the discussion is documented on the meeting minutes (refer artefact No. 7 in Appendix A for a sample copy of meeting minutes). If there is any actionable item attached to the lesson, an owner is assigned to the issue. 3. The meeting minutes are stored on the document management system and can be accessed by the organisation employees. 4. Project Manager reviews these minutes and documents the lessons learnt in a template under the Integrated Project Management Tool (IPMT). (refer artefact No.6 Appendix A for the lessons learnt template). 5. This log is then stored on the document management software and can be accessed by organization employees.  76 6. At the end of the project, a workshop is conducted with the project team to discuss and validate these lessons learnt. Outcome: Lessons learnt or project related new knowledge captured, validated and stored in the document management software 77 BUC 2.3: Sharing lessons learnt. Business Event: Project team wants to view captured lessons learned or project-related new knowledge. Trigger: Project Team member encounters a problem on project/wants to refer to lessons from past projects for planning, risk management, estimating, design etc. Interested Stakeholders: PMO Office, Project Team, Engineering Service. Active Stakeholders: Member of project team. Process: 1. The project team member opens the document management software. 2. Looks for lessons learnt documents in projects. 3. Searches the documents to find relevant lessons learnt. Outcome: Lessons learnt shared.   78 5.4.3 Daily On-Site Logging and Transfer of Data BUC 3.1: Report on labor and equipment hours. Business Event: Site foreman wants to report on the labor and equipment hours. Trigger: Done daily. Interested Stakeholders: Payroll, PMO Office, Superintendent, Foreman. Active Stakeholders: Superintendent, Foreman, Payroll, Engineering Assistant 4 (EA 4). Process: 1. Foreman enters the date, day and location on the timesheet (refer artefact No. 8 to Appendix A for a copy of the timesheet). 2. Foreman enters employee names, type of pay, pay scale. 3. Foreman enter the total hours worked (in time, out time). 4. Foreman enters equipment descriptions and number of equipment. 5. Foreman enters run time and down time for each equipment. 6. At the end of the day, Foreman assigns the sheet to superintendent for review. 7. Superintendent approves the timesheets. 8. Timesheets goes to payroll. 9. Payroll types the timesheets into SAP. 10. Timesheets are stored in boxes in storage facility. Outcome: Labor and equipment hours are recorded and entered into the system. Timesheets are stored in boxes. 79 BUC 3.2: Reporting on safety meetings, near-misses, incidents on-site. Business Event: Site foreman wants to report on safety meetings, near misses and incidents on-site. Trigger: Pre-job, done daily, and when a near miss or incident occurs. Interested Stakeholders: Branch Director, Public, Project Team, Health and Safety Office. Active Stakeholders: Foreman, Superintendent, Clerk, Safety Superintendent. Process: A. Engineering Pre-Job Meetings (refer artefact No. 9 in Appendix A for a copy of the pre-job meeting form) 1. Foreman fills in the date, time and location. 2. In Part 2 of the form, Foreman fills in specific hazards and controls related to: a. Excavation. b. Utilities. c. Traffic Control. d. Overhead Hazards. e. Fall Protection. f. PPE Requirements. g. Confined Space Entry. 3. In Part 3 of the form, Foreman identified hazards specific to site and control measures. 4. In Part 4 of the form, Foreman fills in the employee safety concerns (Hazard and Control). 5. In Part 5, Foreman notes down all employee names who attended the talk. 80 6. Foreman writes down the details of hired equipment (name, company, arrived on-site). B. Safety Meetings (refer artefact No. 10 Appendix A for the copy of safety meeting form) 1. Site operations team holds a daily tailgate talk. 2. Foreman fills in the date, time and location. 3. Foreman fills the tailgate form by hand. a. Site Conditions. b. Safety issues discussion and observations. c. Overhead hazards. d. Excavation checks. 4. Foreman notes down all employees who attended the talk. 5. Foreman signs the tailgate form. 6. Tailgate talk sheet goes to Superintendent for approval. 7. The sheet then goes to the Safety Superintendent in the Operations Safety and Support Branch (OSSB). 8. Tailgate talk sheet is sent to records branch for storage. C. Near Misses/Incidents on-site 1. Near-miss/incidents recorded by paper on hand on the Daily Tailgate sheet. 2. Reported to the safety superintendent. 3. Entered into excel. 4. Stored in the document management software. 5. Looked on a monthly basis as metrics. 6. Reported to director on a quarterly basis. 81 D. Safety Logs (refer artefact No. 11 Appendix A for a copy of the safety log) 1. Superintendent goes on-site. 2. Superintendent walks around site and completes the safety log by hand. 3. The log is sent to OSSB. 4. OSSB forwards it to records and storage branch. Outcome: Daily tailgate talk sheet completed, and near misses’/site incidents recorded and reported. 82 BUC 3.3: Report on daily expenditure. Business Event: Site foreman wants to report on the daily expenditure. Trigger: Done daily. Interested Stakeholders: PMO Office, Superintendent, Foreman. Active Stakeholders: Foreman, Engineering Assistant 4 (EA 4), Superintendent. 1. Foreman fills out the labor hours, materials used and equipment (internal and hired) hours on the PMO Worksheet (refer artefact No. 12 in Appendix A) by hand every day. 2. PMO worksheet is given to Superintendent for approval. 3. PMO worksheet sent to EA 4. 4. EA 4 types the worksheet on Excel. 5. EA 4 prepares a weekly construction report using daily worksheets. Outcome: Daily expenditure is reported. 83 BUC 3.4: Fill daily equipment hired sheet. Business Event: Foreman wants to fill daily hired-equipment sheet. Trigger: Done daily for hired equipment, one form per equipment. Interested Stakeholders: Superintendent, Foreman, Vendor. Active Stakeholders: Foreman, Equipment Operator. Process: 1. Foreman enters the date, start time, vendor name, vendor number and selects the type of service on the sheet (refer artefact No. 14 in Appendix A). 2. Foreman enters the job no, location, task, time out, time back, total hours, and enters his/her initials. 3. Foreman enters the performance ratings on a scale of 1-2 (1- Did not meet, 2- Fully Met) for the equipment with respect to punctuality, following directions, work efficiency, driving practices, working safely and equipment reliability. 4. The foreman must enter comments for rating of 1, and may enter comments for other ratings. 5. Foreman signs the form. 6. Operator signs the form. 7. The form is sent to the equipment superintendent for review, and copies are sent to sewers superintendent and OSSB. Outcome: Daily equipment sheet completed. 84 BUC 3.5: Taking and storing site photos. Business Event: Site staff wants to take and store site photos. Trigger: Done daily. Interested Stakeholders: PMO Office, Foreman, Superintendent, Engineering Services, Third party stakeholders. Active Stakeholders: Foreman, Equipment Coordinator. 1. Foreman takes daily photos on site using a camera. 2. Each day, an SD card (labelled by day) is sent to the equipment coordinator. 3. Equipment coordinator puts them into the right project. Outcome: Site photos taken and stored. 85 BUC 3.6: Generation and completion of third-party documents. Business Event: Foreman requests for BC-1 documents before excavation. Trigger: Needs to be done before excavation. Interested Stakeholders: Third party stakeholders, Project Team, Foreman, Engineering Services. Active Stakeholders: Foreman, Office Clerk, Third party stakeholders. 1. Receive copies from third parties. 2. An office clerk generates and prints the BC-1 sheets. 3. The printed package is sent to site foreman. 4. Reviews the package, signs it off. Outcome: Third-party documents generated and signed. 86 BUC 3.7: Preparing and reporting on daily location sheet. Business Event: Equipment dispatcher wants to prepare and report on a daily location sheet. Trigger: Done daily. Interested Stakeholders: Engineering Services, Foreman, Equipment Dispatcher, Superintendent. Active Stakeholders: Foreman, Equipment Dispatcher, Superintendent. 1. Equipment dispatcher prepares a daily location sheet (refer artefact No. 15 in Appendix A) on excel outlining the location and contact of crew, equipment, trailers, backhoe, and operators name. The information comes through various sources (excels, emails, phone calls). 2. The excel sheet is sent via email to superintendent. Outcome: Daily location sheet prepared and sent out. Notes: 1. The Superintendent must refer back to their email if information regarding excavators, dump trucks etc. is needed from a past date. 2. No metrics on daily location sheet are provided to refer back to old emails or excel reports. 87 BUC 3.8: Report on productivity, 311, health and safety and quality. Business Event: Project team wants to report on productivity, 311 calls, health and safety and quality of project weekly. Trigger: Done weekly. Interested Stakeholders: PMO Office, Third party stakeholders, Project Team, Sewers Design and Operations Branch. Active Stakeholders: Engineering Assistant 4 (EA 4), Superintendent. Process: 1. Engineering Assistant 4 receives details of 311 calls related to the project and adds them to PMO Worksheet (refer artefact No. 13 in Appendix A). 2. EA 4 calculates the productivity (m/day) and adds it to excel. 3. EA 4 looks at the safety incidents from Daily Tailgate Talks, OSSB, Safety Superintendent and adds them to excel. 4. EA 4 refers the timesheets to look at overtime costs and adds them. 5. EA 4 refers to Quality Inspection reports and adds the details. 6. EA 4 sends the details to superintendent for review and approval. 7. All these details are combined with daily expenditure and reported as Weekly Construction Status Reports in Section #3. Outcome: Weekly data on 311 calls, productivity, Health and Safety, and Overtime reported. 88 BUC 3.9: Vehicle inspection reporting. Business Event: Equipment operator wants to conduct a vehicle inspection report. Trigger: Done daily on every vehicle. Interested Stakeholders: Third party stakeholders, Project Team, OSSB. Active Stakeholders: Superintendent, Vehicle Operator, OSSB, Records Branch. 1. Vehicle operator completes the vehicle inspection report by walking around the vehicle refer artefact No. 16 in Appendix A). 2. Form is sent to superintendent for review and approval. 3. Superintendent forwards it to OSSB. 4. OSSB sends it to records branch. Outcome: Vehicle Inspection Complete. 89 BUC 3.10: Complete sewer connection record and inspection report. Business Event: Foreman wants to complete a sewer connection record and inspection report. Trigger: Done whenever a connection is made. Interested Stakeholders: Third party stakeholders, Project Team, OSSB, Engineering Services. Active Stakeholders: Foreman, Superintendent, Records Branch. 1. Foreman completes the inspection record and inspection report (refer artefact No. 17 and 18 in Appendix A). 2. Forms are attached to the permit. 3. Package is sent to superintendent for approval. 4. The package is then sent to records branch. Outcome: Connection record and inspection report is complete. Note: The digital copies of permits received are received by using a software called Posse. 90 BUC 3.11: Site inspections. Business Event: Superintendent wants to conduct monthly site inspections for operations. Trigger: Done once a month. Interested Stakeholders: Third party stakeholders, Project Team, OSSB. Active Stakeholders: Superintendent, OSSB, Records Branch. 1. A representative from OSSB accompanies the superintendent on-site. 2. Superintendent fills the Sewers Site Inspection form by hand (refer artefact No. 19 in Appendix A). 3. Superintendent sends one copy to OSSB and one to records branch. Outcome: Site inspections complete. 91 BUC 3.12: Order/return materials from central store. Business Event: Foreman wants to order/return materials from/to central stores. Trigger: Done whenever an order needs to be placed from central stores. Interested Stakeholders: Third party stakeholders, Project Team, OSSB. Active Stakeholders: Superintendent, OSSB, Records Branch. 1. Foreman enters the branch, account and order number, and cost centre in the requisition form (refer artefact No. 20 in Appendix A). 2. Foreman enters the quantity requested, SKU No., description of order. 3. Foreman signs the form and forwards it to the central stores. 4. The form is delivered through dump trucks/ in-person to central stores. 5. Central stores enter the quantity shipped in the form. 6. Copy of the form is sent to records for storage. Outcome: Order placed from central stores. Notes: Return forms follows the same process. 92 5.4.4 Sharing Project Information Between Design and Construction Teams BUC 4.1: Sharing design drawings. Business Event: Project team wants to share design drawings with site personnel. Trigger:  Project construction is about to begin. Interested Stakeholders:  Site Crew, Design Team, Third party stakeholders. Active Stakeholders: Site Crew, Design Team. Process: 1. Design gets prepared by design branch in AutoCAD. 2. AutoCAD files is saved on the Y Drive (local to the organization). 3. Design drawings (DD) are signed and sealed by Engineer of Record (EoR). 4. DD are then scanned and converted to a pdf. 5. The pdf of DD is filed into the project container in the document management software. 6. Superintendent receives a package of drawings, including necessary permits and the WorkSafeBC BC Notice of Project, via interoffice mail or in-person delivery. Outcome: Design drawings shared. Notes: The drawing set includes colored (4) and BW (3) copies of the drawing for the foreman, back hoe operator, pipe layer, and superintendent.  Any additional copies are printed out when needed. 93 BUC 4.2: Making design changes. Business Event: Project team wants to make design changes. Trigger: A design change is needed. Interested Stakeholders:  Site Crew, Design Team, Third party stakeholders. Active Stakeholders: Site Crew, Design Team, Engineer of Record. Process: 1. Design team goes on-site to discuss the change. 2. For minor changes, site instructions form (refer artefact No. 21 in Appendix A) is issued by a design team member: a. Writes down the project title, project number, design number, site instruction number, date and time of the site instructions. b. Sketches the change on-site or returns to the office to sketch it on the site instruction template. c. Issues the site instruction by having the EoR sign off on the form. d. Site instruction log is updated. e. Scan it, and send a soft copy to site via email. Hard copies are dropped off later. f. Scanned copies stored in the project folder in the document management software. 3. For major changes re-issue of drawings is done: a. Draft changes and record revision in the drawing title block. b. Issue a revision. c. Go to site and give the revised drawing to the crew. Outcome: Design Drawings Shared. 94 BUC 4.3: Sharing of schedule. Business Event: Design team wants to share schedule with operations. Trigger:  Construction Project is being planned for future. Interested Stakeholders:  Water Operations (Superintendent and Site Crew), Design Team, Third party stakeholders, Long Term Planning Group (with the Project Management Office), Residents (in limited circumstances). Active Stakeholders: Water Operations Branch, Design Team. Process: 1. Design calculates the rough time estimates and has all jobs scheduled at a high level in an excel spreadsheet. 2. A person from design manages the master schedule. 3. The schedule is stored in the document management software; currently on a network drive. 4. The master schedule is uploaded on Road Ahead (a google map add-on developed by the organization to convey road closures and construction information to the public), and is sent to Superintendent. 5. Design updates the schedule every week to ensure they are on-track, discuss on activities planned for next week, etc. 6. Schedule changes, if any, are communicated by phone/emails. Collaborative approach in changing schedule. Outcome: Schedule shared. 95 BUC 4.4: Conformance check. Business Event: Design team wants to conduct a conformance check. Trigger:  Done weekly. Interested Stakeholders: Site Foreman, Design Team, Site Superintendent, Crew, Project Manager, Engineering Services, Field reviewer, Engineer of Record (EoR). Active Stakeholders: Field reviewer, Engineer of Record. 1. A field reviewer from Design team goes on-site once a week. 2. Field reviewer notes down date, location, purpose of report and report phase, project title, project number, design number and file location/path (refer artefact No. 22 in Appendix A). 3. Field reviewer specifies the scope of field report. 4. Field reviewer may have a safety discussion prior to filling field report to check the following check boxes: Contractor Controlled Sites, PPE related, Traffic Control. EoR takes notes if required. 5. Field reviewer notes down the field observations and writes them down on a form. 6. Field reviewer checks whether site photos have been taken, drawings are saved to project folder, and if actions have been communicated. 7. These forms are then re-written if needed or typed. 8. Forms are sent to the EoR or designate for review. 9. Forms are scanned or a soft copy is stored in the projects folder in the document management software. 10. Filled forms are available for crew to view, if they ask to see them. Outcome: Conformance checks completed. 96 BUC 4.5: Create red-line drawings. Business Event: Operations team want to create red-line drawings. Trigger: Design changes happened on-site. Interested Stakeholders:  Site Crew, Design Team, Third party stakeholders. Active Stakeholders: Site Crew, Design Team, Engineer of Record. Process: 1. Operations crew is provided access to water-only drawings. 2. Operations crew marks the as-built changes and details on drawings ((refer artefact No. 23 in Appendix A). 3. The red-line drawings along with site instructions are used as as-built drawings. Outcome: Design changes are made on the drawings by crew. 97 5.4.5 Implementing PMO Framework BUC 5.1: Training project management framework to employees. Business Event: PMO office wants to train employees the project management framework. Trigger: Employees require training. Interested Stakeholders: Design and Operations in water and sewers, PMO Office, Equipment Services, Other divisions of Engineering Services. Active Stakeholders: PMO office, Project Coordinators, Project Managers, Learning support specialist. Process: 1. The training resources (user guides, standards, procedures and tools) are published on the PMO website. 2. PMO website has beginner and advanced coursed on Project Management Frameworks online courses and videos directed towards employees. 3. PMO office also conducts two-day training sessions. Outcome: Training delivered. 98 BUC 5.2: Feedback on project management framework. Business Event: Project team has questions/feedback about the PMO framework. Trigger: Employee has questions or wants to provide feedback. Interested Stakeholders: PMO office, Project Team. Active Stakeholders: Employee, PMO Office. Process: 1. Employees go on the PMO website. 2. Employee fills the online feedback form. 3. PMO office gets an email when the form is filled. 4. A response is provided from a PMO representative. The response rate depends on the urgency of the issue such as safety, public impact, costs etc. Outcome: Employee feedback delivered.   99 5.4.6 Implementing Green Operations The BUCs under this area are not clearly defined and are still being developed. However, some of the BUCs identified in this area overlap with the BUCS in knowledge management and collaboration area (i.e. BUC 2.1, 2.2 and 2.3), hence they are not repeated in this section.  5.5 Existing Challenges In addition to understanding and documenting the existing business processes, another focus of the interviews was to identify the existing challenges in the organizations. The two key challenges identified are:  1. Document Management on-site and office: Every day, the project team has to deal with a huge number of paper-based project documents. These include, but are not limited to, timesheets, safety logs, field review forms, BC-1 documents, design drawings, public surveys, crew and equipment location sheets. This often leads to duplication of data due to manual entries on-site followed by digital entries in the office and multiple entries of the same data on different forms. This results in the processes being inefficient and time consuming. This also affects the reliability of data being captured and makes creation of audit trails time-consuming.  These documents are scanned and stored in the document management software, and also sent to the records branch. Searching for documents on the existing document management software or requesting them through the records branch is another challenge that employees face. The existing document management software is considered to be a cumbersome system by many employees, it is difficult to find documents or to use the system in general. The 100 records branch can also take 2-5 days6 to provide employees with the relevant information. This is one key challenge that can be addressed by using suitable construction software.  2. Sharing of Project Information: The Underground Utility (Waters and Sewers) branches within Engineering Services work in silos. The information related to lessons learned, risks, schedule, cost, public feedback is not shared across different project teams. In the current process, the information is contained with the project manager and the project team. As a result, the issues arising in one project are sometimes repeated across other projects, there is a lack of documentation and sharing of standardized project metrics. The Project Management Office has recently started sending monthly project updates and defining metrics; but this information is distributed only amongst the project team. There is no common platform for different project teams from different branches to share their knowledge and collaborate on problem solving. The existing processes for collaboration are ad hoc and often depend on the judgement of project teams.  As per the author’s knowledge, the identified challenges are consistent with the ones other municipal construction organizations are facing. 5.6 Identified Business Use Cases for Investigation Each BUC was reviewed to determine its potential for automation and implementation through a construction software. While shortlisting BUCs, the factors such as organizational culture, existing technology, stakeholder’s feedback and existing challenges were considered. This                                                 6 As mentioned by one of the employees 101 resulted in identifying a total of 23 BUCs which will be developed into product use cases (PUCs). The process of converting BUCs to PUCs is discussed in the next chapter.  102 Chapter 6: Data Analysis 6.1 Introduction This chapter illustrates the approach used to analyze the identified Business Use Cases (BUCs), to derive their corresponding Product Use Cases (PUCs), by use of an example. This is followed by describing the method used to analyze PUCs and the list of functional and non-functional requirements for a potential software solution to address the organization’s information system needs.  6.2 Product Use Cases PUCs are derived from BUCs. They determine the extent of work that will be automated and implemented by the product7 i.e. the construction software. The product contributes to the work being done by the BUC. It does not change the nature of the work; it only changes the way it is done. Each of the 23 identified BUCs in Chapter 5 were analyzed to derive their corresponding PUCs.  6.2.1 Analyzing Business Use Cases The BUCs were analyzed to determine suitable ways through which the software can contribute in achieving their desired outcomes. The following four parameters were considered while defining the software boundaries for each BUC: 1. End-Users: The product end users include project managers, superintendents, foremen, design managers, quality inspectors and residents. The goal was to meet user expectations and                                                 7 The words software and product are used interchangeably since the product is the construction software, which is to be developed. 103 integrate the product with their daily operations. The product should not be perceived as something which requires additional time and effort from the end users. This was achieved through in-depth interviews with the stakeholder and author’s own knowledge about stakeholder’s expectations.  2. Innovation: The innovation refers to thinking differently about the existing way of doing work in order to find a better way. The factors like convenience, connections with public, ease of access to useful information, and speed and security of the product were considered. 3. Technological possibilities and constraints: The existing technologies in the market–such as augmented reality, voice recognition, drones etc.–were considered along with organizational constraints on their use due to the exiting culture, costs and risks involved.  4. Organizational goals: The Organizational and Engineering Services goals discussed in Chapter 4 were also considered when deriving a PUC. The process proposed by Robertson and Robertson (2013) was used to convert a BUC into a PUC. It is illustrated in Figure 6.1 by using an example of BUC 4.5. The figure shows four alternative boundaries represented by the dotted lines, each showing a progressively large scope for a new proposed system. For each dotted line scenario, the steps that appear on the right side are proposed for integration with the product.  In case of boundary number 1, the field reviewer fills the forms by hand, then enters them into the system or re-writes them, and gets them approved by the EoR. The product is then responsible for storing the forms in the project container in the document management software and allowing users to access the forms. 104 Go on-site Fill field review formType forms on the system or re-writes themSend forms to EoR for reviewEoR approves forms Scan FormsStore forms in VanDocsField ReviewerEngineer of Record (EoR)2341Engineer of Record (EoR) Figure 6.1 Deriving PUC from BUC for Quality Inspection On-Site In case of boundary number 2, once the field reviewer has converted the form to digital format, the form is transferred to the product. The field reviewer uses the product to send it to the EoR, and the product stores the form in the project container once it is approved.  In case of boundary number 3, the field reviewer goes on-site and fills the form on the product. As a result, there is no need to type the form again. The field reviewer then uses the product to send it to the EoR and the product stores it once the form gets approved.  In case of boundary number 4, the product fills the field review form by itself and the role of the field reviewer is eliminated. This could be done by using drones on-site; however, this is not feasible currently considering the technological maturity of the organization. The product then follows the same steps as in boundary number 2.  Considering the four scope definitions listed above, boundary number 3 seems the most appropriate solution for the organization. It is within the technological capabilities of the organization, makes the processes more efficient, and eliminates multiple similar entries.  A similar partitioning exercise was conducted with all the other 22 BUCs to derive their corresponding PUCs.  105 6.2.1.1 Stakeholder Feedback In the second round of interviews, a total of five interviews were conducted with the stakeholders. These stakeholders had expertise in the BUCs which were shortlisted for implementation by the software. Each interview lasted for about an hour. During the interview, a new modified process was presented to the stakeholders, and they were asked to share their thoughts and provide feedback. The semi-structured interviews made extensive use of images and process diagrams to convey the future scenarios. The PUCs were modified accordingly to incorporate the feedback.   6.3 Software Requirements Once the stakeholders agreed on the PUC, the next step was to determine the requirements to build the product. Software requirements can be grouped into two categories: functional and non-functional requirements. Functional requirements are like verbs, they specify the functionality of the software indicated by the PUC scenario. Non-functional requirements are like adjectives, they describe the qualities the software must have such as usability, performance, safety, cultural etc. (Robertson and Robertson 2013). The requirements are worded such that they are isolated from any technology that might be used to implement them. They only specify software functionality and the quality of work required from it. It is up to the software developer and designer to determine the best way of implementing the requirements. This allows the software to change and adapt new technology when it is being developed. Each requirement has three essential components: 1. Description: is a complete and unambiguous description of the stakeholder’s intention for the requirement.  106 2. Rationale: specifies the reason for the requirement to exist. It also helps to bring out the real need for the product.  3. Fit Criterion: is the measurement of the requirement and is used to demonstrate that the product has the desired behavior and quality. It is the benchmark against which the product can be tested. The following sub-section describes how the PUCs were analyzed and lists the identified functional and non-functional requirements for the construction software. 6.3.1 Analyzing Product Use Cases Each step in the PUC scenario was analyzed step-by-step to uncover the functionality of the software, i.e. the functional requirements. For each step, the answer to the question “What does the product have to do to complete this step?” was discovered.  In some cases, each step in the PUC represented the functionality of the product whereas, in other cases, the name of the PUC represents the functionality of the product. All the functional requirements along with their rationale and fit criterion have been listed in section 6.3.1.1. In order to gather non-functional requirements, each PUC was considered from the point of view of its active stakeholders. The non-functional requirements were also fleshed out through discussions with stakeholders during the interview process. All the non-functional requirements along with their rationale and fit criterion have been listed in section 6.3.1.2. 6.3.1.1 Functional Requirements There are different ways to write functionally requirements such as atomic requirements, user stories, scenarios and business process models. The IT department at the organization makes use of user stories. Hence, they were chosen as an appropriate form for writing the functional 107 requirements. User stories are most commonly used in agile development methods. The generally accepted template for writing a user story is: “As a [role], I want [functionality] so that [rationale behind the functionality]” The user stories were written in business language and jargon commonly used in the organization so that they can be easily understood by stakeholders. Each user story was written by analyzing the BUCs and PUCs. They were then subjected to a review from stakeholders. The stakeholder satisfaction ratings (i.e. if the user story is implemented by the product) were recorded on a scale of 1 – 5 (1-Not at all satisfied, 5- Very Satisfied). The stakeholder dissatisfaction ratings (i.e. the user story is not implemented by the product) for each user story were recorded on a scale of 1 – 5 (1-Not at all satisfied, 5- Very Satisfied). The use of this form of rating system has been proposed by Robertson and Robertson (2013), it provides a quick and easy way to capture stakeholder feedback. For each PUC, the stakeholder feedback and the author’s opinion, if any, regarding implementation of user stories is summarized in the comments section at the end of all user stories. The details of stakeholder validation and review are provided in Chapter 7. The product use cases and user stories have been grouped by their BUCs and are listed below. The user stories are numbered such that they can be traced back to their business areas and the BUC. For example, for the user story 1.2.1, the first digit from the left (i.e. 1) indicates the first business area, and the second digit (i.e. 2) denotes the BUC in that business area, and the last digit (i.e. 1) denotes the user story number. The numbering of business areas and BUCs is consistent throughout this thesis.    108 6.3.1.1.1 Construction-Related Public Communications Two BUCs from a total of four investigated were selected to be developed into PUCs. The PUCs and corresponding user stories are grouped by their respective BUCs below:  1. BUC 1.2: Public feedback on construction. Business Event: Residents want to provide feedback about the construction in their neighborhood. Product Use Case Scenario: Case A: Continuous Feedback 1. Resident logs onto the system. 2. Resident selects the project on which he/she wants to provide feedback. 3. Resident creates a ticket and fills in the necessary details (subject, category, priority, description, attachments). 4. Resident submits the ticket. 5. Resident is assigned a ticket number. 6. System assigns the feedback to a project team member (CL/CC). 7. The CL/CC receives an email about the ticket being created. Case B: Surveys a. Residents are provided with a link for surveys. b. Resident selects one project and fills the survey. c. Resident submits the survey. d. System generates a dashboard showing key metrics recorded from the survey (not visible to residents, only visible to authenticated users within Engineering Services). 109 User Stories: 1.2.1 As an authenticated resident, I want to be able to fill out and submit an online ticket to the project team during construction so that my concerns are conveyed. Stakeholder Satisfaction8 (1-5): 5  Stakeholder Dissatisfaction9 (1-5): 5 Stakeholder Comments: Connect with service request application, 311 or project website link. 1.2.2 As a project communications coordinator, I want to get notified whenever a public feedback is assigned to me so that I can view it and respond. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5):5 1.2.3 As a resident, I want to be able to access and fill surveys online so that I can provide feedback to project team. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5):4 1.2.4 As an authenticated project communications coordinator, I want to be able to view the survey responses dashboard so that I can share them with the project team. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5):5                                                  8 Stakeholder satisfaction rating of 1 means that the stakeholder is not at all satisfied if the user story is implemented by the software, whereas a rating of 5 means the stakeholder is very satisfied if the user story is implemented. A higher rating means it is this user story is important to stakeholders.  9 Dissatisfaction rating of 1 means the stakeholder is not at all dissatisfied if the user story is NOT implemented by the product, whereas a rating of 5 means the stakeholder is very dissatisfied if the user story is NOT implemented by the software. A higher rating means it is this user story is important to stakeholders.  110 Comments  As per the feedback of stakeholders, all user stories for this PUC are equally important to the stakeholders. In case of user story 1.2.3, the dissatisfaction is relatively lower because the respondents can still have access to paper surveys. However, this can only add on to the existing system since not everyone has access to laptops, phones, internet etc. It will streamline the process of feedback management. It also makes it easier to define metrics, use data coming from public feedback, and makes the current manual process more efficient.   111 2. BUC 1.4: Response to public feedback. Business Event: Project team wants to respond to public feedback. Product Use Case Scenario: 1. Community Liaison (CL)/Communications Coordinator (CC) logs onto the system. 2. CL/CC opens the ticket and provides a ranking to it. 3. CL/CC gets bi-weekly reminders until the ticket is resolved. 4. Resident gets weekly updates regarding the status of their ticket. 5. CL/CC take appropriate steps to resolve the issue and provides a response (consulting with other project team members, personal judgement/knowledge). 6. CL/CC marks the ticket as resolved and submits it. 7. Resident is notified once the ticket is resolved. 8. Resident can view the response provided by the CL/CC. 9. System stores the ticket in the project archived. User Stories: 1.4.1 As an authenticated project communications coordinator, I want to be able to view and respond to tickets created by public so that they can be addressed. Stakeholder Satisfaction (1-5): 5   Stakeholder Dissatisfaction (1-5):5 1.4.2 As an authenticated project communications coordinator, I want to be able to mark the tickets as resolved once I have provided the feedback so that the resident can be notified. Stakeholder Satisfaction (1-5): 5   Stakeholder Dissatisfaction (1-5):5 1.4.3 As an authenticated resident, I want to be notified when someone responds to my feedback so that I am made aware of the response. 112 Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5):5 1.4.4 As an authenticated resident, I want to be receive weekly updates on the status of my tickets so that I am made aware of the progress. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 1.4.5 As an authenticated project communications coordinator, I want to be able to rank the tickets so that important issues/concerns are highlighted and resolved first. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 3 Comments  As per the stakeholder feedback, user stories 1.4.1 to 1.4.4 are equally important to them. In case of user story 1.4.5, the stakeholder’s dissatisfaction seems neutral (rating of 3) in case the user story is not implemented by the product. However, in author’s opinion user story 1.4.5 is an important functionality which the product should have.  113 6.3.1.1.2 Knowledge Management and Collaboration All three BUC from this business area were selected to be developed into PUCs. The PUCs and user stories corresponding are grouped by their respective BUCs below. 1. BUC 2.1: Reporting and sharing project status. Business Event: Project team wants to know about the project status (schedule, costs, risks, green operations etc.) of other projects during planning or execution of new projects. Product Use Case Scenario: 1. Site foreman/Superintendent and other relevant stakeholders including communications group, health and safety group enter weekly construction status on the system (various metrics related to progress, costs, risks, change orders, health and safety issues, public feedback, site photos). 2. Project manager enters details of lessons learned, risks realized and upcoming risks, issues related to project scope on the system. 3. The system compiles all the information from different sources and updates the project dashboard. 4. System generates a monthly report and emails it to project manager for review. 5. Project manager approves the report and the system sends the report to the project stakeholders. User Stories: 2.1.1 As a project manager, I want to be able to generate project reports so that I can review and send them to the project stakeholders. Stakeholder Satisfaction (1-5): 5   Stakeholder Dissatisfaction (1-5): 4 114 2.1.2 As a project stakeholder, I want to be able to see the various metrics with respect to scope, schedule, budget, risk of projects so that I am aware of the project status. Stakeholder Satisfaction (1-5):5    Stakeholder Dissatisfaction (1-5):4 2.1.3 As a project stakeholder, I want to be able to view additional information on each metric so that I can use it in planning of current or future projects and aid decision making. Stakeholder Satisfaction (1-5):5    Stakeholder Dissatisfaction (1-5):4 Comments  The dashboard is envisioned as a platform which shows project status for different on-going projects in different Engineering Services Branches. It is meant to facilitate sharing of information within and amongst the Underground Utility and streets branches in Engineering. As per stakeholder’s feedback, the satisfaction ratings are same for all the user stories i.e. stakeholder will be very satisfied if the product implements these user stories. In case of dissatisfaction ratings, the stakeholder will be dissatisfied if any of the user stories above is not implemented by the software.    115 2. BUC 2.2: Capture Lessons Learned Business Event: Project team wants to capture lessons learnt or project related new knowledge. Product Use Case Scenario: 1. Project team member logs onto the system. 2. Project team member selects the project for which a lesson learned has to be entered. 3. System pre-enters the date, project details and allocates a unique number to the lesson. 4. Project Team member enters the details of lesson learned onto the software. 5. Selects the category/knowledge area of problem. 6. Enters a title, originator and keywords of the lesson learned. 7. Enters details of lesson learned (What happened, what was supposed to happen, what accounts for the difference). 8. Enters the solution devised and applied. 9. Enters the learnings to be reused for future projects (What should have been done differently). 10. Project Team member assigns the lesson learned to the Project Manager to review. 11. Project manager reviews the lesson learned details, approves it, and enters a frequency rating. 12. Project manager shares the lesson learnt with project team and engineering services branches. 13. Project team is notified of the lesson learnt through an email. User Stories: 2.2.1 As an authenticated project team member, I want to be able to enter the details of lessons learnt so that new knowledge/learnings can be captured and shared with Underground Utility and Streets branches. 116 Stakeholder Satisfaction (1-5): 5   Stakeholder Dissatisfaction (1-5):5 2.2.2 As an authenticated project team member, I want to assign the lesson learned to a Project Manager so that it can be approved. Stakeholder Satisfaction (1-5): 5   Stakeholder Dissatisfaction (1-5):5 2.2.3 As an authenticated project manager, I want to get a notification when a lesson learned is assigned to me so that it can be reviewed and approved. Stakeholder Satisfaction (1-5): 5   Stakeholder Dissatisfaction (1-5):5 2.2.4 As an authenticated project manager, I want to be able to give a frequency rating to each lesson so that repetitive lessons learned can be easily identified. Stakeholder Satisfaction (1-5): 5   Stakeholder Dissatisfaction (1-5):5 2.2.5 As an authenticated project manager, I want to be able to share the lesson learnt with the project team and engineering services so that they can view it. Stakeholder Satisfaction (1-5): 5   Stakeholder Dissatisfaction (1-5):5 2.2.6 As a project team member, I want to get a notification when a lesson learned is approved so that I may view it. Stakeholder Satisfaction (1-5): 5   Stakeholder Dissatisfaction (1-5):5 Comments  As per stakeholder’s feedback, all user stories are equally important and should be implemented. The author also agrees with the stakeholder’s feedback.   117 3. BUC 2.3: Sharing Lessons learnt. Business Event: Project team wants to view captured lessons learned or project related new knowledge. Product Use Case Scenario: 1. Project team member logs onto the system. 2. Project team member searches for lessons learned in the software. 3. Software returns a list of lessons learned related to the search. a. CASE 1: Required Lesson Learned Available. i. Project Team Member refers to the lessons learned. ii. Project Team Member applies it on the project. iii. Project Team Member may provide feedback on the solutions refereed. b. CASE 2: Required Lesson Learned not available. i. Follow Product Use Case No. 2.2. User Stories: 2.3.1 As an authenticated project team member, I want to be able to search for and view the past lessons learned so that I can apply them on my current or future projects. Stakeholder Satisfaction (1-5): 5   Stakeholder Dissatisfaction (1-5):5 2.3.2 As an authenticated project team member, I want to be able to provide feedback on the lesson learned entries so that my knowledge about the lesson learned can be shared and captured. Stakeholder Satisfaction (1-5): 1   Stakeholder Dissatisfaction (1-5):1 118 Stakeholder Comments: Conflict issues between different project managers, instead the review of different lessons learned should be done by a third party in PMO (Quality Manager/ Process and Standards Manager) through an open workshop of project managers. 2.3.3 As an authenticated third party reviewer, I want to be able to update the lessons learned so that the stakeholder’s feedback is reflected in the final entry. Stakeholder Satisfaction (1-5) 5   Stakeholder Dissatisfaction (1-5):4 Stakeholder Comments: The update should be done by third party reviewers in Project Management Office (Quality Manager/ Process and Standards Manager). The feedback should be gathered through workshops. Comments As per stakeholder’s feedback, user story 2.3.2 should not be implemented by the software. While, the other user stories are important to the stakeholder. The author’s opinion is in agreement with the stakeholder’s feedback.    119 6.3.1.1.3 Daily On-Site Logging and Transfer of Data All three BUC from this business area were selected to be developed into PUCs. The PUCs and user stories corresponding are grouped by their respective BUCs below. 1. BUC 3.1: Report on labor and equipment hours. Business Event: Site foreman wants to report on the labor and equipment hours. Product Use Case Scenario: In the product use case, the foreman is able to record the labor and equipment hours directly on the mobile friendly form while in the field. The superintendent can audit or edit and approves it and it is forwarded to payroll. There is no re-entry of data by payroll and the hours are sent into SAP-the financial management system at the organization. The timesheets are stored in the system for future reference. User Stories: 3.1.1 As an authenticated foreman, I want to be able to fill the daily digital timesheets on the field so that they can be sent to the superintendent for approval. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 3.1.2 As an authenticated foreman, I want to be able to share the timesheets with the superintendent so that they can be approved. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 3.1.3 As an authenticated superintendent, I want to be able to audit, edit and approve the timesheets so that they can be sent to payroll. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 120 3.1.4 As a payroll employee, I want to be able to view the timesheets so that I can upload them onto SAP. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 Stakeholder Comments: No delays with paper delivery stream to yard anymore. Currently, there are dedicated people who drop off timesheets. Comments As per stakeholder’s feedback, all user stories are equally important and should be implemented by the product. The author also agrees with the stakeholder’s feedback.   121 2. BUC 3.2: Reporting on Safety Meetings, Near-Misses, Incidents on-site. Business Event: Site foreman wants to report on safety meetings, near misses and incidents on-site. Product Use Case Scenario: In the new system, the foreman is able to complete the digital mobile friendly version of the Engineering pre-job meeting, engineering daily tailgate talk form and also record the near miss/incidents. The foreman can also take site photos and attach them to the form. The software autofill’s some fields such as Date, Location, Time. User Stories: 3.2.1 As an authenticated foreman, I want to be able to fill the digital engineering pre-job safety meeting form so that the identified safety hazards and control measures can be documented and shared. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 3.2.2 As an authenticated foreman, I want to be able to fill the digital Engineering Daily Tailgate form so that the safety issues and hazards can be documented and shared. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 3.2.3 As an authenticated foreman, I want to be able to record near misses/incidents so that the safety issues and hazards can be documented and shared. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 4 3.2.4 As an authenticated superintendent I want to able to view the Engineering Daily Tailgate so that I can review and approve it. 122 Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 4 3.2.5 As an authenticated foreman, I want to be able to click and attach photos to safety forms so that my observations can be recorded and shared. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 3.2.6 As a safety superintendent, I want to be able to receive and view the safety forms (daily tailgate, engineering pre-job meeting, near-miss forms) so that they can be audited and used for metrics. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 3.2.7 As an authenticated safety superintendent, I want to be able to view and approve the near-miss/incident forms so that I am made aware of the incidents happening on site. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 3.2.8 As an authenticated safety superintendent I want to be able to share the weekly incident reports with the project team members so that they are made aware of the safety incidents which occurred on-site. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 3.2.9 As an authenticated project team member, I want to be able to view weekly reports on near-misses’/safety incidents on-site so that I am aware of the weekly incidents happening  Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 Comments As per stakeholder’s feedback, all user stories are equally important and should be implemented. The author also agrees with the stakeholder’s feedback.  123 3. BUC 3.3: Report on daily expenditure. Business Event: BUC Site foreman wants to report on the daily expenditure. Product Use Case Scenario: 1. Foreman enters the materials used on daily basis on the PMO worksheet. 2. System auto-populates the other sections (labor and equipment) by using data from timesheets. 3. Foreman sends the PMO worksheet to the superintendent. 4. Superintendent approves it. 5. System enters the cumulative data into weekly expenditure sheet. 6. System generates a weekly construction expenditure report. User Stories: 3.3.1 As an authenticated foreman, I want to be able to fill the PMO worksheet so that that daily usage of resources can be recorded. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 3.3.2 As a superintendent, I want to be able to view the PMO worksheet so that I can approve it. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 Comments As per stakeholder’s feedback, all user stories are equally important and should be implemented by the product. The author also agrees with the stakeholder’s feedback.  124 4. BUC 3.4: Fill daily equipment hired sheet. Business Event: Foreman wants to fill daily hired equipment sheet. Product Use Case Scenario: Foreman is able to fill the digital mobile friendly version of this form. User Stories: 3.4.1 As an authenticated foreman, I want to be able to complete the daily hired equipment form so that details of the hired equipment can be recorded and shared. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 3.4.2 As an equipment superintendent I want to be able to view the daily hired equipment form so that I am aware of the equipment use and availability. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 Comments As per stakeholder’s feedback, all user stories are equally important and should be implemented by the product. The author also agrees with the stakeholder’s feedback.  125 5. BUC 3.5: Taking and storing site photos. Business Event: Site staff wants to take and store site photos. Product Use Case Scenario: 1. Foreman logs onto the system. 2. Foreman selects the project. 3. Foreman takes site photos using the software on his/her mobile device. 4. Foreman marks up/adds comments to the photos. 5. Software assigns the photos in the project folder. Notes: There is no equipment coordinator involved. User Stories: 3.5.1 As an authenticated foreman, I want to be able to take site photos so that site conditions can be recorded. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5  3.5.2 As an authenticated foreman, I want to be able to comment/annotate on site photos so that my observations can be captured. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 Comments As per stakeholder’s feedback, all user stories are equally important and should be implemented by the product. The author also agrees with the stakeholder’s feedback.  126 6. BUC 3.6: Generation and Completion of third-party documents. Business Event: Foreman requests for third-party documents before excavation. Product Use Case Scenario: 1. Office clerk compiles all digital copies received and creates a package. 2. Package is sent to foreman for review. 3. Foreman reviews the digital package on-site. 4. Foreman signs off on the package. User Stories: 3.6.1 As an authenticated site foreman, I want to be able to view and sign the third-party documents so that excavation work can begin on the project. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 4 3.6.2 As an authenticated office clerk, I want to be able to upload the package on the software so that it can be sent to the site foreman. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 Comments As per stakeholder’s feedback, all user stories are important and should be implemented by the product. The author also agrees with the stakeholder’s feedback. The current process involved a lot of manual processes, and use of paper. There are dedicated staff for printing and creating a package of these third-party documents. This PUC can potentially save these work hours, and make the process easier and more efficient.   127 7. BUC 3.7: Preparing and reporting on daily location sheet. Business Event: Equipment dispatcher wants to prepare and report on Daily Location Sheet. Product Use Case Scenario: 1. Equipment dispatcher requests the software for daily location sheet. 2. Software generates the sheet by using information from timesheets (refer BUC 3.1), and employee information available on the system. 3. Equipment dispatcher reviews the sheet for completeness and sends to superintendent. User Stories: 3.7.1 As an equipment dispatcher, I want to be able to request the software to generate daily location sheet so that I can review and circulate it. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 3.7.2 As an equipment dispatcher, I want to be able to review and edit the daily location sheet so that any missing entries can be completed.  Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 3.7.3 As a superintendent, I want to be able to view daily the location and contact details of crew and equipment on various construction sites so that I am aware of the accuracy of our planning and to evaluate daily crew sizes. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 Comments As per stakeholder’s feedback, all user stories are equally important and should be implemented by the product. The author also agrees with the stakeholder’s feedback.  128 8.  BUC 3.8: Report on productivity, 311, health and safety and quality. Business Event: Project team wants to report on productivity, 311 calls, health and safety and quality of project weekly. Product Use Case Scenario: In the new process, the software gets information on productivity, health and safety, cost and overtime from BUC 3.1, 3.2, 3.3. The software also extracts 311 calls information from the 311 system. Engineering Assistant 4 (EA 4) is only responsible for inspecting quality reports and entering the total percentage of passing. The software populates section #3 of PMO worksheet (refer artefact No. 13 in Appendix A) with this information (BUC 3.3) and reports it as weekly construction status reports. The superintendent reviews the combined PMO worksheet (refer to User Story 3.3.2). User Stories: 3.8.1 As an EA 4, I want to be able to request the software to generate data on productivity, cost, 311 calls, health and safety incidents on a daily basis so that project KPIs can be recorded and reported. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 3.8.2 As an EA 4, I want to be able to enter the pass percentage of quality testing in the PMO worksheet so that it can be recorded and reported. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 Comments As per stakeholder’s feedback, all user stories are equally important and should be implemented by the product. The author also agrees with the stakeholder’s feedback 129 9.  BUC 3.9: Vehicle inspection reporting. Business Event: Equipment operator wants to conduct a vehicle inspection report. Product Use Case Scenario: Vehicle operator fills the form on the software and send it to superintendent. User Stories: 3.9.1 As an authenticated vehicle operator, I want to be able to fill the vehicle inspection form so that any defects or damages can be recorded and reported. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 Comments As per stakeholder’s feedback, all user stories are equally important and should be implemented by the product. The author also agrees with the stakeholder’s feedback   130 10. BUC 3.10: Complete sewer connection record and inspection report Business Event: Foreman wants to complete a sewer connection record and inspection report. Product Use Case Scenario: The foreman fills the form on the software and forwards it to the superintendent. The software accesses the permit from the existing software system in use called Posse. User Stories: 3.10.1 As a foreman, I want to be able to fill the sewer connection and inspection report so that the details of the connection can be recorded for future reference. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 Comments As per stakeholder’s feedback, all user stories are equally important and should be implemented by the product. The author also agrees with the stakeholder’s feedback.  131 11. BUC 3.11: Site Inspections. Business Event: Superintendent wants to conduct monthly site inspections for operations. Product Use Case Scenario Superintendent fills a digital copy of the site inspection form on the software. User Stories 3.11.1 As a superintendent, I want to be able to fill the site inspections form so that the site conditions can be recorded. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 Comments As per stakeholder’s feedback, all user stories are equally important and should be implemented by the product. The author also agrees with the stakeholder’s feedback.  132 12. BUC 3.12: Order/return materials from central store. Business Event: Foreman wants to order/return materials from/to central stores. Product Use Case Scenario 1. Foreman completes the digital copy of form on the software while on-site and forwards to central stores. 2. Central stores add the quantity shipped. 3. The form is archived by the software. User Stories 3.12.1 As a foreman, I want to be able to complete the central stores requisition/return form on-site so that I can order/return the required materials. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 Comments As per stakeholder’s feedback, all user stories are equally important and should be implemented by the product. The author also agrees with the stakeholder’s feedback. 133 6.3.1.1.4 Sharing Project Information Between Design and Construction Teams Four out of the five BUCs from this business area were selected to be developed into PUCs. The PUCs and corresponding user stories are grouped by their respective BUCs below. 1. BUC 4.1: Sharing design drawings. Business Event: Project team wants to share design drawings with site personnel. Product Use Case Scenario: 1. The design branch uploads the AutoCAD file onto the system. 2. The drawing is reviewed by operations to highlight constructability issues. Comments and annotations are returned back to design branch. 3. Design reviews the operations comments and incorporates the necessary changes. 4. Design drawings are signed and sealed by utility branches and the EoR. 5. Design is converted to a pdf and uploaded onto the software. 6. Design is shared with the project team. 7. Project team member logs on the system and views the drawing. User Stories: 4.1.1 As authenticated designer, I want to be able to upload the AutoCAD drawings onto the system so that they can be reviewed by the Engineer of Record and Operations, and for record keeping to inform future designs. Stakeholder Satisfaction (1-5): 4  Stakeholder Dissatisfaction (1-5): 4 Stakeholder Comments: Utility branches (Sewers and Waters) review it and sign off on all designs. 134 4.1.2 As an authenticated project team member, I want to be able to view the design drawings so that I can use them for construction. Stakeholder Satisfaction (1-5): 4  Stakeholder Dissatisfaction (1-5): 2 Stakeholder Comments: A mounted stand would be required for the backhoe operator. 4.1.3 As an authenticated Engineer of Record, I want to be able to sign the design drawings so that they can be shared with the project team and used for construction. Stakeholder Satisfaction (1-5): 3.5  Stakeholder Dissatisfaction (1-5):4 Stakeholder Comments: In the future, as Engineers get used to electronic seals and reviewing drawings. This functionality will be much more useful. 4.1.4 As an authenticated operations group member, I want to be able to comment and annotate on the drawings so that the constructability issues and conflicts are identified and communicated. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5):3 Stakeholder Comments: Operations input into design is very important. This is one of many advantages of having internal crews to build infrastructure projects. Many companies pay significant amount to have early contractor involvement that the organization gets for ‘free’.  Comments The stakeholder’s feedback for each user story can be interpreted through stakeholder comments for each user story provided above. Overall, the stakeholder seemed satisfied with all the user stories. However, the dissatisfaction ratings for 4.1.2 points out that it a nice to have and not a must have functionality.    135 2.  BUC 4.2: Making design changes. Business Event: Project team wants to make design changes. Product Use Case Scenario: 1. Design Manager goes on-site to discuss the change and changes are made as follows. 2. For minor changes issue site instructions. a. Design Manager enters project name into the software. b. Design Manager selects site instruction form for the selected project. c. Software auto-fills the project number, design number, site instruction number, date and time into the site instructions form. d. Design Manager sketches the change on the site instruction template in the software. e. Design Manager takes feedback from the operations and makes the necessary changes on-site. f. Design Manager assigns the form to the Engineer of Record (EoR) for review. g. EoR annotates/comments on the site instructions. h. The site instruction form is signed by Engineer of Record (EoR). i. Design Manager assigns site instruction form to the site foreman. j. Site Foreman views the site instruction. k. Software updates the site log. l. Software archives the site instruction. 3. For major changes new drawings are issued. a. Draft changes and record revision in the drawing title block. b. Issue a revision. c. Update the file in the software and assign to site personnel. 136 User Stories: 4.2.1 As an authenticated design manager, I want to be able to sketch on the site instructions form so that the design changes can be communicated/recorded. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5):3.5 4.2.2 As an authenticated design manager, I want to be able to assign the site instructions form to the Engineer of Record (EoR) so that it can be approved. Stakeholder Satisfaction (1-5): 4  Stakeholder Dissatisfaction (1-5):3 4.2.3 As an authenticated EoR, I want to be able to annotate and comment on the site instructions so that I can provide feedback. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5):5 Stakeholder Comments: EoR must have the ability to comment on site instructions. 4.2.4 As an authenticated EoR, I want to be able to sign on the site instructions form so it can be approved. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5):4 Stakeholder Comments: Not wasting Paper, speeding up process. 4.2.5 As an authenticated site foreman, I want to be able to view the site instruction so that the design changes can be made on-site correctly. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5):4 Stakeholder Comments: Good to have a drawing to view, they will design formally to guide work v/s verbal direction which is given sometimes in the existing system. 4.2.6 As an authenticated design manager, I want to be able to assign the site instructions form to the site foreman so that design changes can be made on-site. 137 Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5):5 Comments The stakeholder’s feedback for each user story can be interpreted through stakeholder comments for each user story provided above. Overall, the stakeholder seemed satisfied with all the user stories. However, the dissatisfaction ratings for 4.1.2 points out that it a nice to have and not a must have functionality.   138 3. BUC 4.4: Conformance Check. Business Event: Design team wants to conduct a conformance check. Product Use Case Scenario: 1. Field Reviewer logs onto the system. 2. Field reviewer fills the field review form on the software. 3. Field reviewer clicks and annotates pictures if required. 4. Field reviewer assigns action items to the project team member as requires such as issue site instruction, save marked drawings in project folder etc. 5. Field Reviewer signs the form on the software. 6. Field Reviewer approves some of the action items and assigns the rest to EoR for review. 7. Field reviewer assigns the form to EoR for review and signatures. 8. Software assigns the action items to relevant team members. 9. Team member get notified about the action items assigned to them. 10. Software saves the form in the projects folder on local drive/the document management software. User Stories: 4.4.1 As an authenticated field reviewer, I want to be able to fill the different sections of a field report so that the field review can be recorded. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 4.4.2 As an authenticated field reviewer, I want to be able to click, annotate and attach pictures to the field report so that site conditions can be recorded. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 4  139 4.4.3 As an authenticated field reviewer, I want to be able to assign action items to project team member so that they are made aware of their work tasks. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 3 4.4.4 As a project team member, I want to receive a notification when an action item is assigned to me. Stakeholder Satisfaction (1-5): 4  Stakeholder Dissatisfaction (1-5): 4 4.4.5 As an authenticated field reviewer, I want to be able to sign the field review form so that it can be send to the EoR. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 5 4.4.6 As an authenticated field reviewer, I want to be able to approve the action items so that they can be assigned to respective employees. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 4 4.4.7 As an authenticated EoR, I want to be able to review and sign the field review form so that it can be approved and action items are assigned. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 4 Comments As per stakeholder’s feedback, all user stories are important and should be implemented by the product. The author also agrees with the stakeholder’s feedback. 140 4. BUC 4.5: Create red-line drawings. Business Event: Operations team want to create red line drawings. Product Use Case Scenario. In the product use case, the operations crew is able to access the drawings through the software and make changes on them. The person can also click pictures and attach to the marked up drawings. The new process is as follows. 1. Operations crew is provided access to water only drawings through software. 2. Operations crew marks changes on soft copy drawings. 3. Operations crew clicks pictures using the software and attaches them to the red-line drawings. 4. Software stores the red-line drawings and pictures in the projects folder. User Stories. 4.5.1 As an authenticated project team member, I want to be able to view drawings so that I can compare them with the as-built condition. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 4 Stakeholder Comments: This is required as per Organizational Quality Management program (OQM). 4.5.2 As an authenticated project team member, I want to be able to mark-up on drawings so the design changes can be recorded. Stakeholder Satisfaction (1-5): 4  Stakeholder Dissatisfaction (1-5): 3 Stakeholder Comments: Learning curve for workers involved. 141 4.5.3 As an authenticated project team member, I want to be able to take pictures and attach them to drawings so that the as-built condition can be recorded. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 4 Stakeholder Comments: Very useful for quality control. 4.5.4 As an authenticated project team member, I want to be able to store the red-line drawings and the pictures in the project folder so that they can be archived. Stakeholder Satisfaction (1-5): 5  Stakeholder Dissatisfaction (1-5): 4 Comments As per stakeholder’s feedback, user stories 4.5.1, 4.5.3, 4.5.4 are important and should be implemented by the product. In case of user story 4.5.2, the stakeholder is neutral in the dissatisfaction rating if the user story is not implemented. The author also agrees with the stakeholder’s feedback.  142 6.3.1.1.5 Fit Criterion for Functional Requirements Functional requirements define the behavior of the product i.e. the things that the product must do. There are no scales of measurement for functional requirements. They are either performed by the product or not. The fit criterion for each user story is that it has been successfully implemented by the product. Consider the following user story: “As an authenticated operations group member, I want to be able to comment and annotate on the drawings so that the constructability issues and conflicts are identified and communicated”. The fit criterion is that the tester should ensure that the operations group member is able to comment and annotate the drawings. A similar fit criterion can be used for other user stories. 6.3.1.2 Non-Functional Requirements. The description of non-functional requirements for the software, along with the rationale and fit criterion is below. They have not been grouped since they apply to all the PUCs. 1. Description: The software shall be easy to use. Rationale: To ensure that employees easily integrate the software into their daily work and voluntarily switch to using it. Fit Criterion: Within 3 months of introducing the software, eighty percent of the users shall be using it to carry out the agreed-upon work. 2. Description: The software shall appear authoritative. Rationale: To ensure that users feel confident using it and rely on its data for decision making. 143 Fit Criterion: Within 3 months of introducing the software, it should be used as a primary source of data required for decision making by users OR After the first encounter with the product, eighty percent of the users shall feel that they can trust the product. 3. Description: The software shall use terminology familiar to the Engineers, Superintendents, Foremen and Project Managers in the organization. Rationale: To ensure that the users are able to easily interpret and understand the software. Fit Criterion:  The communications department shall certify that the software is acceptable for the intended users. 4. Description: The users shall be able to use the software on construction sites, i.e. noisy environment, uneven terrain and changing weather conditions (rain, sunshine, snow). Rationale: These are the likely conditions encountered on construction sites on a daily basis. Fit Criterion: The user shall successfully complete the different tasks on time in less or equal time as compared to the existing time for the task. The software shall have the same performance and usability as it does in indoor environment. 5. Description: The software shall avoid asking users to duplicate any entered data. Rationale: To save users time and improve productivity. Fit Criterion: The user survey results after one month of implementation shall reveal that more than ninety-five percent data entered by the users is new data. 6. Description: The software shall comply with the established look and feel and branding of organization. Rationale: This is a required for every software used within the organization. 144 Fit Criterion: The Digital Strategy, IT and Communications department shall certify that the look and feel and branding of the software matches with the established software norms in the organization. 7. Description: The software should allow to set customized user access (open or restricted) to different sections and data in the software. Rationale: To build confidence amongst the users, and ensure security of the system. Fit Criterion: The authorized users (IT Dept., Branch Managers) shall be able to customize user access and rights for different sections and data in the software. 8. Description: The software shall present data in a manner that prevents further or second-hand use by unauthorized people. Rationale: To build confidence amongst the users, and ensure security of the system. Fit Criterion: The unauthorized users shall not be able to access the software. 9. Description: The software shall be able interoperable with the software and computer systems currently in use in the organization (MS Outlook, MS Word, Adobe PDF Reader, MS Excel, the document management software, Posse, SAP, Hansen, local intranet website). Rationale: To ensure that the data can be accessed, stored and transferred across the different software systems. Fit Criterion: The software shall comply with the interoperability standards to ensure data communication with the systems mentioned above. 10. Description:  The users shall be able use the software offline – enter, store and access files. Rationale: Construction sites often do not have connectivity to the Internet. 145 Fit Criterion: The software should be able to temporarily store the data on the local device and synchronize it to the cloud when the connection becomes available. 11. Description: The software shall ensure that the data being transferred across different system or software is accurate. Rationale: To ensure the integrity of data and the fact that it can be relied upon. Fit Criterion: The data transferred by the software should be cross-checked with the data from the source. 12. Description: The software shall be readily portable to iOS devices and Windows systems. Rationale: The organization currently supports iOS mobile devices on-site and Windows systems in offices. Fit Criterion: The software shall be developed as per the requirements for iOS and Windows systems. 13.  Description: The software shall support a cloud based environment for accessing, storing and transferring of data. Rationale: To allow access to large files on mobile devices which have low memory space. Fit Criterion: The software allows all users to easily access and transfer files having size up to 10 GB (depends on size of drawings). 14. Description: The software shall allow the user to directly manipulate all interface items. Rationale: To simplify data manipulation for the user. Fit Criterion: Eighty percent of the users shall be satisfied with data manipulation features of the software. 146 15. Description: The software shall prevent all personal and confidential data from being printed. Rationale: To build confidence amongst the users and meet the policies of the organization. Fit Criterion: None of the users shall be able to print data marked as personal and confidential unless authorized by the IT department.  16. Description: The software shall store all personal and confidential data of employees on local servers in Canada. Rationale: To build confidence amongst the users and meet the policies of the organization. Fit Criterion: The testers should ensure that data is being stored in local servers. 17. Description: The software shall track all data required for to maintain an audit trail as required by the organization. Rationale: To meet the requirements for auditing by the payroll office, project management office and organizations policies. Fit Criterion: The different branches using the software shall certify that the audit trail meets the organizational requirements. 18. Description: The software shall have self-guided training resources for users.  Rationale: There will be no training and support office for the software, the users should be able to self-learn the software. Fit Criterion: Eight percent of the users should have learned how to use the software within the first month of its implementation.  147 6.4 Software Development: Next Steps After having identified the requirements, the next step is developing the software and developing class diagrams, use case diagrams and systems architecture. These future steps are not in the scope of this thesis. However, some high-level use case and system architectures diagrams are shown in the subsequent sections to aid future software development.    148 6.4.1 High-Level Software Use Case Diagram The high level use case diagram for the software system is shown in Figure 6.2 Capture	lessons	learnedView	lessons	learnedProject	ManagerForemanCoV	authenticated	employee	Project	team	member	ResidentCommunications	CoordinatorThird	party	reviewerProvide	FeedbackView	project	dashboardsView	public	feedbackRespond	to	public	feedbackGenerate	project	status	reportsReview	lessons	learnedUpdate	lessons	learnedReport	on	labor	and	equipment	hoursReport	on	safety	meetings,	near-misses	and	incidentsReport	on	daily	expenditureFill	daily	hired	equipment	sheetClick	site	photosComplete	BC-1	documentsGenerate	daily	location	sheetConduct	Site	InspectionOrder	materials	from	central	storeSuperintendentShare	design	drawingsIssue	site	instructionsConduct	conformance	checkCreate	red-line	drawingsDesign	team	memberField	reviewerApprove	forms Figure 6.2 High-Level Use Case Diagram 149 6.4.2 High-Level Software Architecture Diagram The high-level software architecture diagram is shown in Figure  Cloud ServersTrailer LaptopsOffice WorkstationsDatabaseStakeholderOn-site mobile devices and tabletConstruction Software Figure 6.3 High-Level System Architecture Diagram 150 Chapter 7: Validation of Requirements 7.1 Introduction After identifying the requirements in Chapter 6, the next step (before developing the software) is to ensure that they are precise, complete and unambiguous statements of the real need. There were two steps involved: verification and validation.  The verification step is intended to ensure that the requirements are precise and logically follow from the business and product use cases. This was done through analyzing each requirement using a self-checklist and stakeholder reviews.  The validation step was intended to ensure that the requirements can be used by developers in the organization to develop the software or outsource the development to a third party. The case organization should also be able to select one of the existing commercially available software based on these requirements. This step was completed through using my own knowledge of software development, and conducting a third party review with a software developer from the IT department in the organization.  This chapter describes the three approaches (self-checklists, stakeholder review and third party review) used for verifying and validating the requirements.  7.2 Self-Checklists Each functional and non-functional requirement was assessed on the basis of checks listed in Table 7.1. This table was developed by referring to quality gateway activity described by Robertson and Robertson (2013) in their book. The Quality Gateway is used to test each requirement to ensure its suitability.  151 Table 7.1 Checklist for Testing Quality of Requirements (Adapted from Robertson and Robertson (2013)) Checks Questions Traceability 1. Can it be traced back to its business and product use cases?   2. Are the naming and conventions easily understandable? Completeness 1. Are stakeholder, function, and rationale present in the user story? Relevancy 1. Does the requirement align with the goals/purpose of the product?  Consistency 1. Have all terms used been clearly defined in a non-ambiguous manner in the data dictionary wherever required?  Fit Criterion 1. Does the requirement have a correctly defined fit criterion? 2. Can the fit criterion be used as input when designing acceptance tests? Viability 1. Does the organization have technological skills to include this functionality?  2. Will the stakeholders be able to execute this functionality easily?  3. Is the requirement acceptable to stakeholders?  Abstractness 1. Does the requirement have any technological content? 2. Is it written in a way that it describes a specific type of procedure?  3. Is it a solution?  Requirement Value 1. Are stakeholder satisfaction and dissatisfaction ratings provided for user stories?  152 7.3 Stakeholder Verification and Ratings The stakeholder feedback was used to verify the functional requirements. Each of the product use case and their corresponding user stories were presented to the stakeholders in one-on-one interviews. The product use case was first explained through using process diagrams, and the future process was described i.e. when the software is implemented. The stakeholders were asked for their feedback and to review each of the user story to ensure that it meets their needs and expectations. The stakeholders were also asked to provide ratings with respect to their satisfaction level if the user story was implemented, and their dissatisfaction level if the user story was not implemented. The stakeholder feedback was incorporated in the user stories through modifying or adding new user stories when required. Their ratings and comments have been included with each user story in Chapter 6.  The non-functional requirements emerged through interviews and were defined through a collaborative process with the stakeholders. Hence, they did not require a verification from the stakeholders. However, they were subjected to a third party review for validation.  7.4 Review from the IT Group in the Case Organization The functional and non-functional requirements were subjected to a review from an expert in software development. For this thesis, the expert was identified from the IT Group in the case organization. Each requirement was discussed through one-on-one meetings, and the corresponding business and product use cases were explained. The expert was asked to review the requirements from the point of view of developing the software by the organization. The developer was also asked to review the fit criterion for the functional and non-functional requirements. The feedback from the developer was incorporated through modifying the requirements as needed. 153 Chapter 8: Conclusion  8.1 Conclusion The primarily goal of this research was to identify requirements for a construction software to improve the design and construction operations of a case organization. In particular, the focus was on the Underground Utilities (Water and Sewers) and Project Management branches which fall under the Engineering Services division. This research has resulted in a mapping the several business processes (in form of BUC scenarios) of the respective branches, identifying the existing challenges, and the requirements (both functional and non-functional) for a potential construction software. These were the objectives listed in Chapter 1, and have been achieved in this dissertation.  Currently, there are several commercial construction software and collaboration platforms available as was shown in Chapter 2. However, the literature reviewed in the IT in construction domain does not explicitly point towards the core requirements for a construction software, or provide construction organizations with a way to find out their own requirements. As a result, these organizations find it challenging to select the right software, which can be easily integrated and adopted by their employees for daily use. Many organizations often implement software using a top-down approach i.e. the upper management makes a decision and it is pushed down to the employees. This approach, although it does work sometimes, often results in software being perceived as an extra burden by the employees and does not lead to a successful integration.  This thesis illustrated a structured bottom-up stakeholder engagement approach for requirements gathering through using a case study of an organization. This approach has been adapted from knowledge available in the software engineering field, and was slightly modified to suit the needs of construction organizations. The preliminary investigation conducted on a 154 construction project, described in Chapter 2, laid emphasis on the importance of a bottom-up stakeholder engagement approach. Each chapter of this thesis elaborated the different steps used in the approach and made use of examples from the organization to illustrate them. Chapter 4 laid out the organizational context and defined the scope of this research. The stakeholder engagement conducted and development of business use cases was described in Chapter 5. Chapter 6 presented a method to analyze the existing business processes and flesh out the functional and non-functional requirements. Chapter 7 explained the validation of requirements through stakeholder and expert reviews.  The other main contribution of this thesis (in addition to meeting the objectives for the organization under study) is that it provides construction organizations, who are looking to adopt software for their design and construction operations, with a structured approach to identify their internal software requirements. The work done in this thesis can be used as a guideline for other construction organizations to conduct their own stakeholder engagement. It can help them to identify the requirement for a software, which can improve their existing design and construction processes. Some of the requirements identified in this thesis can also be re-used by other organizations, especially municipalities looking to adopt construction software.  8.2 Future Work The future work can be done at two levels:  1. Organizational Level: The case organization can move forward with development of the software, which can be done in-house or can be contracted out. The organization can also select one of the commercially available software through presenting the identified requirements in this thesis. This would result in a hard validation of the study, by making use of both qualitative and quantitative data regarding software usage.  155 2. Future Research Directions:  a. The prototypes of a construction software, using the requirements identified, can be developed and tested with stakeholders. This can ultimately result in development of a single software, or a suite of software which can improve design and construction operations.  b. This research can be extended to other municipalities involved in infrastructure construction, or construction organizations looking to adopt construction software. This could potentially result in identifying a core set of requirements for construction, and may also refine the approach used in this thesis for stakeholder engagement.  8.3 Limitations of Work A few limitations of this research are:  1. Data Collection: The primary source of data collection was through semi-structured interviews with the employees. When conducting interviews, it is inevitable to avoid bias from creeping in. Efforts were made to minimize bias through the careful design of the questionnaire and by developing relevant interviewing skills. However, it’s difficult to say with certainty that there was no bias involved in the interviews.  2. Business Case for the Software: The business case for the software, i.e. the analysis of the cost for developing the software and the potential benefit in monetary terms, was not performed since it is not within the scope of this thesis. However, this is a critical step for the organization to move forward with its development. The preliminary business case comes from employee’s feedback regarding the use of software which points out that the organization should invest in a construction software. Additionally, the fact that the use of construction software has been 156 successfully used in other organizations provides reason to believe that it will benefit the case organization as well.   157 Bibliography Aconex. (2016). “Our product solutions.” <http://www.aconex.com/solutions> (May 22, 2016). Ahsan, S., El-hamalawi, A., Bouchlaghem, D., and Ahmad, S. (2007). “Mobile Technologies for Improved Collaboration on Construction Sites Mobile Technologies for Improved Collaboration on Construction Sites.” Architectural and Design Management, 257–272. Al-Ghassani, A. M., J.Anumba, C., Carrillo, P. M., and S.Robinson, H. (2005). “Tools and Techniques for Knowledge Management.” Knowledge Management in Construction, Blackwell Publishing Ltd. Anumba, C., Aziz, D., and Carrillo, P. (2003). “Towards a Web of Construction Knowledge and Services.” Towards a Vision for Information Technology in Civil Engineering, 1–11. Armstrong, R. (2015). “Mobile IT in Construction: keep taking the tables.” Institution of Civil Engineers- Civil Engineering. AT&T. (2015). “AT&T Toggle: Your complete Bring Your Own Device (BYOD) solution.” <https://www.business.att.com/content/productbrochures/att-toggle-solution-brief.pdf> (Nov. 15, 2015). Atlas RFID Solutions. (2015). “What is Jovix?” <http://atlasrfid.com/jovix-overview/> (Nov. 20, 2015). AutoDesk. (2016). “BIM 360: Collaborative Construction Management Software.” <http://www.autodesk.com/products/bim-360/overview> (Jan. 10, 2016). AYO Smart Home. (2015). “UBC Pilot Home.” <http://www.ayosmarthome.com> (Dec. 1, 2015). Boehm, B. (1986). “A spiral model of software development and enhancement.” ACM SIGSOFT Software Engineering Notes, ACM, 11(4), 14–24. 158 Bowden, S., Dorr, A., Thorpe, T., and Anumba, C. (2006). “Mobile ICT support for construction process improvement.” Automation in Construction, 15, 664–676. BuilderTREND. (2016). “Cloud based home builder and remodeler software.” <https://www.buildertrend.com/tour.aspx> (May 27, 2016). CANARIE. (2015). “Interactive, energy efficient building design optimized for how people live.” <http://canarie.ca/software/platforms/green2_0/> (Dec. 1, 2015). Chen, Y., and Kamara, J. M. (2011). “A framework for using mobile computing for information management on construction sites.” Automation in Construction, Elsevier B.V., 20(7), 776–788. COMIT. (2005). Taylor Woodrow-Snagging. COMIT. (2015). NDL and Amey UK: Automating Safe Dig Packs. Dave, B., Boddy, S., and Koskela, L. (2010). “Improving information flow within the production management system with web services.” 18th Annual Conference of the International Group for Lean Construction, Haifa, 445–455. Dave, B., and Koskela, L. (2009). “Collaborative knowledge management-A construction case study.” Automation in Construction, Elsevier B.V., 18(7), 894–902. Elvin, G. (2003). “Tablet and wearable computers for integrated design and construction.” American Society of Civil Engineers Construction Research Congress, 19–23. Ferrada, X., Sepulveda, M., Serpell, A., Nunez, D., and Neyem, A. (2014). “A lessons learnt mobile system for construction companies.” Creative Construction Conference, 157–165. Fieldwire. (2016). “The construction app for the field.” <http://www.fieldwire.com/blueprint-app/> (May 22, 2016). Flowfinity. (2015a). “City of Cincinnati Case Study.” 159 <http://www.flowfinity.com/customers/field-service-management-mobile-solution-city-of-cincinnati.aspx> (Nov. 1, 2015). Flowfinity. (2015b). “Flowfinity customers.” <http://www.flowfinity.com/customers/> (Nov. 1, 2015). Flowfinity. (2016). “Flowfinity Products.” <http://www.flowfinity.com/apps/> (Jan. 10, 2016). Grover, R., Li, P., and Froese, T. M. (2015). “The Interface Between Building Information Model And The Public.” 5th Construction Speciality Conference, Vancouver. Hansen, M., Nohria, N., and Tierney, T. (1999). “What’s your strategy for managing knowledge?” Harvard Business Review, 77(2), 106–16. HCSS. (2016). “Software Built for Construction.” <http://www.hcss.com/products/> (Jun. 4, 2016). Hiranabe, K. (2008). “Exploring User Requirements through Mind mapping.” IBM. (2015). “IBM Connections.” <http://www-03.ibm.com/software/products/en/conn> (Dec. 10, 2015). JBKnowledge. (2015). The 4th Annual Construction Technology Report. Jive. (2015). “Jive-n: Collaboration without complication.” <https://www.jivesoftware.com/about-jive/news-room/press-releases/collaboration-without-complication-jive-unveils-a-simplified-mobile-interactive-intranet> (Dec. 12, 2015). Keegan, A., and Turner, R. (2001). “Quantity versus quality in project-based learning practices.” Management Learning, 32(1), 77–98. Kietzmann, J. H., Hermkens, K., Mccarthy, I. P., and Silvestre, B. S. (2011). “Social media ? Get serious ! Understanding the functional building blocks of social media.” Business Horizons, 54, 241–251. 160 Kim, C., Park, T., Lim, H., and Kim, H. (2013). “On-site construction management using mobile computing technology.” Automation in Construction, Elsevier B.V., 35, 415–423. Kimoto, K., Endo, K., Iwashita, S., and Fujiwara, M. (2005). “The application of PDA as mobile computing system on construction management.” Automation in Construction, 14, 500–511. Kivrak, S., Arslan, G., Dikmen, I., and Birgonul, M. T. (2008). “Capturing Knowledge in Construction Projects :” (April), 87–95. McAfee, A. . (2006). “Enterprise 2.0: The Dawn of Emergent Collaboration.” MIT Sloan Management Review, 47(3), 21–28. McGraw Hill Construction. (2013). Information Mobility: Improving team collaboration through the movement of project information. Microsoft. (2015). “Yammer: Change the way you work.” <https://products.office.com/en-ca/yammer/yammer-features> (Dec. 1, 2015). Microsoft. (2016). “SharePoint-Connect with employees across the enterprise.” <https://products.office.com/en-us/sharepoint/connect-with-employees-across-the-enterprise> (Feb. 1, 2016). Newell, S., Laurent, S., Edelman, L., Scarbrough, H., Swan, J., and Bresnen, M. (2004). “Sharing learning across projects : Limits to Current ‘ Best Practice ’ Initiatives.” Business, (April). Olofsson, T., and Emborg, M. (2004). “Feasibility study of field force automation in the Swedish construction sector.” Journal of Information Technology in Construction, 285–295. Panahi, S., Watson, J., and Partridge, H. (2012). “Social Media and Tacit Knowledge Sharing : Developing a Conceptual Model.” World Academy of Science, Engineering and Technology, 64, 1095–1102. 161 Panahi, S., Watson, J., and Partridge, H. (2013). “Towards tacit knowledge sharing over social web tools.” Journal of Knowledge Management, 17(3), 379–397. PROCORE. (2016). “Procore Mobile: The Mobile Construction Application Leader.” <https://www.procore.com> (May 25, 2016). Robertson, S., and Robertson, J. (2013). Mastering the requirements process. Addison-Wesley. Saidi, K. S., Haas, C. T., and Balli, N. A. (2002). “The Value of Handheld Computers in Construction by.” 19th International Symposium on Automation and Robotics in Construction, Gaithersburg, Maryland, 1–6. Secutor Solutions LLC. (2016). “Lessons Learned Database Features and Benefits.” <http://secutorsolutions.com/Software> (May 25, 2016). Shelbourn, M., Bouchlaghem, N. M., Anumba, C., and Carrillo, P. (2007). “Planning and implementation of effective collaboration in construction projects.” Construction Innovation: Information, Process, Management, 7(4), 357–377. Shoolestani, A., Shoolestani, B., Froese, T., and Vanier, D. J. (2015). “SocioBIM: BIM-to-end user interaction for sustainable building operations and facility asset management.” The Canadian Society for Civil Engineering 5th International/11th Construction Specialty Conference, Vancouver. Sitrion. (2015). “Sitrion: Be Productive in the Moment.” <http://www.sitrion.com/media/Pages/Resources/sitrion-one-enterprise-mobility-solution-productive-in-the-moment-jan2016.pdf> (Nov. 1, 2015). Swan, J., Newell, S. H., Scarbrough, H., and Hislop, D. (1999). “Knowledge management and innovation: networks and networking.” Journal of Knowledge Management, 3(4), 262 – 275. 162 Tan, H. C., Anumba, C. J., Carrillo, P. M., Bouchlaghem, N. D., Kamara, J. M., and Udeaja, C. E. (2010). Capture and Reuse of Knowledge in Construction. Wiley-Blackwell. Tan, H. C., Carrillo, P. M., Anumba, C. J., Asce, M., Bouchlaghem, N. D., Kamara, J. M., and Udeaja, C. E. (2007). “Development of a Methodology for Live Capture and Reuse of Project Knowledge in Construction.” Journal of Management in Engineering, 23(1), 18–26. UDA Technologies. (2016). “UDA Construction Online.” <http://www.constructiononline.com/index.html> (Feb. 1, 2016). Venkatraman, S., and Yoong, P. (2009). “Role of mobile technology in the construction industry - A case study.” International Journal of Business Information Systems, 4(2), 195–209. Viewpoint. (2016). “Vista by Viewpoint.” <http://viewpoint.com/products/vista-by-viewpoint> (May 25, 2016). Vuori, V., and Okkonen, J. (2012). “Knowledge sharing motivational factors of using an intra-organizational social media platform.” Journal of Knowledge Management, 16(4), 592–603. Wahlroos, J. (2010). “Social media as a form of organizational knowledge sharing. A case study on employee participation at Wärtsilä.” University of Helsinki. Wilkinson, P. (2005). Construction Collaboration Technologies, The extranet evolution. Taylor and Francis Group. Willson, C. (2013). Interview Techniques for UX Practioners: A User Centered Design Method. Morgan Kaufmann, Morgan Kaufmann Publishers. Zimmerman, J. . (1999). Mobile computing: Characteristics, business benefits, and the mobile framework (Tech. Rep. No. INSS 690 CC). Zou, W., Ye, X., Peng, W., and Chen, Z. (2006). “A Brief Review on Application of Mobile Computing in Construction 1.” First Internationa Multi-Symposiums on Computer and 163 Computational Sciences, 2–6.  164 Appendices Appendix A  : Artefacts Associated with Business Use Cases 1. Sample Notification letter corresponding to BUC 1.1, 1.2     ENGINEERING SERVICES Peter Judd, P.Eng., General Manager     City of Vancouver, Engineering Services Mailing Address: 320-507 West Broadway Vancouver, British Columbia V5Z 0B4 Canada tel: 3-1-1, Outside Vancouver 604.873.7000 fax: 604.873.7200 website: vancouver.ca/engsvcs/   April 20, 2015   RE:   CONSTRUCTION NOTIFICATION – W King Edward Ave (Quesnel Drive – Granville Street)  Please be advised that street construction is scheduled to start in your neighbourhood on May 4, 2015. This project will enable the City of Vancouver to enhance your neighbourhood by:   1. Rehabilitating spot locations of curb and gutter, sidewalk and disability ramps along W King Edward Ave between Quesnel Drive and Granville Street 2. Paving the full width of W King Edward Ave between Quesnel Drive and Granville Street (shown in red below) 3. Installing drain tile to improve drainage between Macdonald Street and Cypress Street (shown in blue below)    Curb and gutter, sidewalk, disability ramps and drain tile work will start the week of May 4, 2015 and continue through August 2015. Following the completion of this work, the full width of W King Edward Ave between Quesnel Drive and Granville Street will be paved. Paving work is tentatively scheduled for July and August 2015.   Working hours for construction will typically be 7:00am – 3:30pm, Monday to Friday. All work on W King Edward Ave is expected to be completed by September 2015. Advanced notice will be provided for any work required outside of our permitted working hours (as per Section 17 of the City’s Noise Control By-law No. 6555).  During construction, some lane closures and parking restrictions will be in effect. On W King Edward Ave, at least one lane of traffic will be maintained in each direction and buses will be accommodated via construction signage and/or traffic flaggers. The City will endeavour to provide as much residential parking as possible after working hours.   For schedule updates please visit vancouver.ca/roadwork or call 3-1-1 for more details regarding the project. If you have any questions about this project, please contact me, Joel Clary, Project Manager, at 604-873-7746.   We apologize for any inconvenience this may cause and we appreciate your cooperation.   Yours truly,  Joel Clary  Engineering Services, City of Vancouver 165 2. Sample Notification letter corresponding to BUC 1.1, 1.2         ENGINEERING SERVICES  Jerry Dobrovolny, P.Eng., General Manager     City of Vancouver, Engineering Services Mailing Address: 320-507 West Broadway Vancouver, British Columbia V5Z 0B4 Canada tel: 3-1-1, Outside Vancouver 604.873.7000 fax: 604.873.7200 website: vancouver.ca/engsvcs/    March 2, 2016   RE:   x Temporary long term closure of west lane entrance/exit due to traffic lane closures and sewer construction on Burrard Street        TO THE OWNER OR OCCUPANT:  Please be advised that the lane adjoining your property will be closed at one end to facilitate upcoming sewer construction on Burrard St. This work is part of a larger infrastructure project on Burrard St. between Davie St. and West 17th Ave, including Burrard Bridge rehabilitation. For more information, please see the project website at: vancouver.ca/burrardcorridor   Important information:  x Starting approximately March 14th, the lane between Broadway and West 10th Ave. will be closed at the west entrance/exit for approximately 12 weeks.  x Access to the lane will only be possible from Pine Street. Please use caution, especially around garbage and recycling trucks, which may be required to back up into, or out of the lane.   x During this time there will be no parking or stopping in the lane at any time. Please ensure that delivery vehicles are not blocking the lane. A temporary 24 hour loading zone will be established on West Broadway near Pine St. that can be used for smaller deliveries.   We apologize for the inconvenience and thank you in advance for your patience and co-operation.  Questions regarding the project can be directed to the Project Community Liaison Officer, Do Nguyen at burrardstreet@vancouver.ca or 604-673-8458.    Yours truly,  Farhan Rafique Project Manager City of Vancouver   166 3. Public Communication Log corresponding to BUC 1.2        167          168 4. Sample Public Feedback Survey corresponding to BUC 1.2  City main sewer reconstruction crews work hard to provide efficient, high qualityservice while minimizing disturbance to the public. Your comments are a veryimportant source of information that will be used to ensure that these goals areachieved.How are you submitting your comments?Sewer Construction Service Survey50%OnlinePhone ( 3-1-1; Outside Vancouver 504-873-7000)Mail (Use the self-addressed envelope to return your survey)Sewer Construction Service Survey - 50% http://vancouver.fluidsurveys.com/s/sewersurvey/?__cache_ke...1 of 4 2016-06-27, 1:33 PM169  Notification ofthe constructionproject wasgiven in a timelymanner.Content in thenotification letterwas informativeand helpful.Constructioncrews made areasonable effortto maintainaccess to yourstreet.ConstructionLocation:Type hereName (Optional): Type herePhone#(Optional):Type hereAddress: Type hereDate of Service:(DD/MM/YYYY)Type herePlease check off the appropriate response to the following statements. A box may beleft blank if the statement doesn't apply to your experience.Poor Unsatisfactory Satisfactory Good ExcellentSewer Construction Service Survey - 50% http://vancouver.fluidsurveys.com/s/sewersurvey/?__cache_ke...2 of 4 2016-06-27, 1:33 PM170  non-workinghours.The constructionsite was safe andwell marked.The constructionsite has beentemporarilyrestored to yoursatisfaction.(Note: Crews maytemporarily repairthe road, with apermanent repair ata later date.)Constructioncrews werecourteous andwilling to answeryour questions.Your overallopinion of theservice received.Poor Unsatisfactory Satisfactory Good ExcellentPlease use the space below for any additional comments you mayhave. (Check the box which best describes your comments.)Road Restoration Crew/Staff Kudos Notifications Access ParkingDowntime OtherSewer Construction Service Survey - 50% http://vancouver.fluidsurveys.com/s/sewersurvey/?__cache_ke...3 of 4 2016-06-27, 1:33 PM171    SubmitiBackType hereSewer Construction Service Survey - 50% http://vancouver.fluidsurveys.com/s/sewersurvey/?__cache_ke...4 of 4 2016-06-27, 1:33 PM172 5. Project Status Report corresponding to BUC 2.1  173  174 175 6. Lessons Learnt Template corresponding to BUC 2.2 176 7. Sample meeting minutes corresponding to BUC 2.2  177 8. Sample Copy of Timesheet    178 179 9. Sample Copy of Engineering Pre-Job Meeting Form  180   181 10. Sample Copy of Daily Tailgate Talk   182   183 11. Sample of Site Safety Log   184 12. Daily Construction Reporting Form on Expenditure and KPIs   185 13. Weekly Construction Status Report     186 14. Daily hired equipment sheet   187 15. Daily crew and equipment location sheet 188 16. Sample copy of Vehicle Inspection Report    189 17. Sample copy of Sewer Connection Record 190 18. Sample copy of Sewer Inspection Report    191 19. Sample form for Sewer Site Inspections Operations  192 xc193 20. Sample Materials Order and Return Form   194 195 21. Sample copy of Site Instructions Form    196 22. Sample copy of Field Review Form    197    198    199 23. Sample copy of Red Line Drawings (Highlighted with light faded Lines)     200 Appendix B  : Sample Interview Questions  All interviews had some generic questions, and some specific questions relating to the business area. The interview questions have been classified below. Please note, this list only consists of some basic questions which were used in the semi-structured interview. During the interview further questions were asked depending on the response of the interviewee.  A. Generic Questions Q1. What are the challenges that stakeholders related to this process currently face?  Q2. Do you feel having a construction software can improve existing processes? If yes, which ones in particular? Q3. What are your expectations from the software? (This was mainly intended to flesh out the non-functional requirements) B. Business Event Specific Questions with Engineering Services 1. Construction related communications with public 1.1. Engineering Services wants to share information about the upcoming construction with residents  Q1. How does Engineering Services share information with citizens about the upcoming construction in their neighborhood?  Q2. What all information is shared? At what stage of the project is it shared? Q3. Is there any other information you feel should be communicated to the citizens?  Q4. During construction, is there a way for project team to share information? If yes, how? If not, would to like to have that?  201 1.2. Residents want to provide feedback about the construction in their neighborhood Q1. How do citizens provide feedback about the construction being done or completed in their neighborhood?  Q3. How does the organization keep a record of citizen feedback/complaints for each project?  Q4. What all things are they asked for in the survey? How is the survey administered?  Q5. Are there any other ways of getting citizen feedback?  Q6. If there was a new system that automates part of this work, ensures everything is stored in a central location, provides a digital method for citizens to provide feedback and is accessible to different project teams. Would that be useful?  1.3. The project team wants to know about the public feedback/ KPIs related to it Q1. How is the PT/ES notified of the public feedback/KPIs? Q2. How do they share the feedback within branches/project teams?  1.4. Project team wants to respond to public feedback/queries Q1. How does ES/PT respond to public feedback? Any other ways? Q2. How are citizens notified of the response?  Q3. What happens when they are not able to respond to public feedback? 2. Knowledge Management and Collaboration 2.1. Project team wants to know about the project status (schedule, costs, risks, green operations etc.) of other projects during planning or execution of new projects 202 Q1. What is the current process? What’s the frequency?  Q2. Who is responsible for creating the project status report? Q3. How is it shared? Amongst who all?  Q4. Where does the information in the report comes from? 2.2. Project team wants to capture lessons learnt or project related new knowledge Q1. What is the current process? What’s the frequency? At what phase of the project is it done?  Q2. Who is responsible for capturing the lessons learnt? Where are they stored? Q3. How is it shared? Amongst who all?  Q4. Where does the information in the report comes from? Q5. Are they validated for future reuse in project? 2.3. Project team wants to view captured lessons learned or project related new knowledge Q1. What is the current process? How does project team access lessons learned? Q2. What happens when a similar lesson learned is already entered?  3. Daily on-site logging and transfer of data 3.1. Site foreman wants to report on the labor and equipment hours Q1. How are the labor and equipment hours reported? Q2. What is the frequency? Q3. How are they communicated to the payroll?  3.2.  Site foreman wants to report on safety meetings, near misses and incidents on-site 203 Q1. How are the safety incidents recorded on-site? Q2. Who records them? Q3. What happens during the safety meetings on-site? 3.3. Site foreman wants to report on the daily expenditure Q1. How is the daily expenditure recorded? Q2. Where is it stored? Q3. How is it communicated? 3.4. Foreman wants to fill daily hired equipment sheet Q1. How is the daily hired equipment sheet filled? Q2. What happens to it after it is filled? Q3. How can someone access them in the future? 3.5. Site staff wants to click and store Site Photos  Q1. How are daily site photos captured? Q2. How are they transferred to office? Q3. How is it shared with the superintendent/project team? 3.6. Foreman requests for BC-1 documents before excavation Q1. Who creates the BC-1 package? Where do the documents come from? Q2. How is the package sent on-site, and in what form? Q3. How does the foreman complete the BC-1 package? 204  3.7. Equipment dispatcher wants to prepare and report on Daily Location Sheet Q1. How is the daily location sheet prepared? What all is entered in the sheet? Q2. Where does the data come from? Q3. Who gathers the data? Q4. How can someone access the sheet in the future? 3.8. Project team wants to report on productivity, 311 calls, health and safety and quality of project weekly Q1. How is the productivity on-site reported? Q2. How are the 311 calls reported? Q3. Who collects the data? Who analyzes it? 3.9. Equipment operator wants to conduct a vehicle inspection report.  Q1. How is a vehicle inspection done? What’s the frequency? Q2. What happens to the report once it is completed?  a. . Foreman wants to complete a sewer connection inspection report Q1. How is a sewer inspection done? What’s the frequency? Q2. What happens to the report once it is completed?  b. . Superintendent wants to conduct monthly site inspections for operations Q1. How is the site inspection done for operations? 205 Q2. How is it recorded? Q3. Where is it stored? c. . Foreman wants to order/return materials from/to central stores Q1. How are materials ordered? How are they returned? Q2. Who is responsible for ordering materials? Q3. How is the inventory maintained? 4. Sharing project information between design and construction teams  4.1. Project team wants to share design drawings with site personnel  Q1. How is the design created for projects? Q2. How are design drawings shared with the operations team? What’s the format? Q3. How are design clarifications communicated? 4.2. Project team wants to make design changes Q1. What happens when a design change is required? Q2. How is it communicated? Q3. How is it recorded? 4.3. Design team wants to share schedule with operations Q1. How is the schedule shared with the operations? Q2. How is the schedule updated? What’s the format? 4.4. Design team wants to conduct a conformance check Q1. How are site inspections performed by design teams? Q2. How is it recorded? How is it communicated? 206 Q3. How are action items assigned?  4.5. Operations team want to create red line drawings Q1. How does the site crew record design changes on the field? Q2. Where are they recorded? How is it communicated? Q3. How is it stored?  Q4. How is the change reflected on the as-built condition change? 5. Implementing PMO framework 5.1. PMO office wants to train employees the project management framework Q1. How is the PMO training employees regarding the different project management processes and protocols developed? Q2. How is the training being assessed? Q3. How many employees are being trained? Q4. What communications means are being used for training? 5.2. Project team has questions/feedback about the PMO framework.  Q1. How do employees submit questions/feedback regarding use of the framework? Q2. How are their concerns addressed? 6. Implementing Green Operations  6.1. Sustainability office wants to share innovative methods or materials for greening construction operations with design and construction teams  207 Q1. How does information regarding green operations get shared across different project in Engineering Services? Q2. Is there a way to encourage use of innovative green solutions across projects? 6.2. Sustainability office wants to communicate to crew regarding the goals and objectives of Green Operations as it relates to Engineering Services Q1. How are the goals and objectives related to green operations communicated to the site crew? C. Interviews with IT and Digital Strategies Group Q1. What type of web-based applications has your group developed for Engineering Services or any other department in the case organization? (Service Request Application, Online Management of Permits, Field Reports Application) Q2. What process did you follow to capture the user requirements (Hardware and Software)? Q3. How are these web-based applications perceived by the employees? Q4. Did you look into factors such as integration with existing technologies, training and support for staff, availability of wireless network on-site?  Q5. Did you do any pilot runs of the application before releasing it? If yes, what process did you follow? 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
https://iiif.library.ubc.ca/presentation/dsp.24.1-0308598/manifest

Comment

Related Items