UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Application and re-use of information and knowledge in managing risks of infrastructure projects De Zoysa, Garumuni Niranjan Sanjaya 2006

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

Item Metadata

Download

Media
831-ubc_2006-129832.pdf [ 34.77MB ]
Metadata
JSON: 831-1.0092941.json
JSON-LD: 831-1.0092941-ld.json
RDF/XML (Pretty): 831-1.0092941-rdf.xml
RDF/JSON: 831-1.0092941-rdf.json
Turtle: 831-1.0092941-turtle.txt
N-Triples: 831-1.0092941-rdf-ntriples.txt
Original Record: 831-1.0092941-source.json
Full Text
831-1.0092941-fulltext.txt
Citation
831-1.0092941.ris

Full Text

A P P L I C A T I O N A N D R E - U S E O F I N F O R M A T I O N A N D K N O W L E D G E I N M A N A G I N G R I S K S O F I N F R A S T R U C T U R E P R O J E C T S by r G A R U M U N I N I R A N J A N S A N J A Y A D E Z O Y S A B . S c , The University o f Moratuwa, Sri Lanka, 1996 M . A . S c , The University o f Brit ish Columbia, Canada, 2000 A T H E S I S S U B M I T T E D I N P A R T I A L F U L F I L L M E N T O F T H E R E Q U I R E M E N T S F O R T H E D E G R E E O F D O C T O R O F P H I L O S O P H Y in T H E F A C U L T Y O F G R A D U A T E S T U D I E S ( C i v i l Engineering) T H E U N I V E R S I T Y O F B R I T I S H C O L U M B I A January 2006 © Garumuni Niranjan Sanjaya De Zoysa, 2006 Abstract The management of economic risks is critical for the success of major infrastructure projects. A s with other management challenges, the tasks associated with risk management rely heavily on knowledge and experience, and also involve the use of a diverse and sizeable set o f information. Thus, computer-based methodologies that can allow the application and re-use o f information and knowledge have the potential to be particularly useful to an organization in managing risks. Described in this thesis are the results of an effort to develop such a methodology. The methodology represents the risks and the context to which they apply by considering five dimensions or views. The five dimensions are the Risks, the Physical components o f the project, the Processes required to procure and operate it, the Organizational entities involved, and the Environment in which it is being procured and operated. The methodology facilitates the creation of enterprise-level ontologies or libraries for each of these views. The libraries which can be augmented over time are made up o f components relevant to a particular view which are modeled in a project-neutral format. Information and knowledge that is relevant to supporting project risk management is modeled within the components. In analysing the risks o f an individual project, the methodology facilitates the development o f project-specific models for each o f the five dimensions for that particular project making use o f the content o f the libraries. The relationship between the context and risks is modeled through a driver-issue relationship and refined using the notion o f spatial and temporal gateways. The methodology also allows the user to leverage the representations to derive insights such as the distribution of risks among spatial location and among project participants, and the evolution of risks as project conditions change. It is anticipated that the functionality provided for re-using information and knowledge and for leveraging available information w i l l assist an organization in identifying a more complete set of risks, in providing more refined input to economic models used in decision making, and in deciding on appropriate risk assignments, thus bringing an organization closer to achieving success on the projects they undertake. ii Table of Contents Abstract i i Table o f Contents i i i List o f Tables v i List o f Figures v i i Abbreviations x i i i Acknowledgements x iv Dedication xv 1 Introduction 1 1.1 Managing the Economic Risks o f Infrastructure Projects 1 1.2 Objectives and Contributions o f the Research 4 1.3 Research Scope and Anticipated User Audience 5 1.4 The Research Path 8 1.5 Structure o f the Thesis 10 1.6 Case Studies 11 2 State o f the Ar t o f Risk Management and Knowledge Management 16 2.1 The Risk Management Process 16 2.2 Risk Management in the P3 Context 22 2.3 Knowledge and its Management 28 2.4 Use of Information Technology in Knowledge Management 31 2.5 Management o f Risk-related Information and Knowledge 42 3 Beyond the State o f the Ar t - Challenges and the Solution Paradigm 52 3.1 Introduction 52 iii 3.2 The State of the Art and Beyond 56 3.3 Risk Workshops 64 3.4 Definitions 68 3.5 A n Ontological Approach 75 3.6 The Model l ing Paradigm of K R I S 79 4 Modeling of the Project Context 89 4.1 The Significance o f the Environment in Project Risk Management 89 4.2 Current Approaches Towards Representing the Project Environment 90 4.3 Representing the Environment in Support o f Risk Management 94 4.4 Project Environmental Mode l 123 4.5 Values of Component Attributes 125 4.6 The Significance o f the Physical, Process, and Organizational Domains in Project Risk Management 134 4.7 Current Approaches Towards Representing the Physical, Process, and Organizational Domains 135 4.8 Representing the Physical, Process, and Organizational Dimensions in Support o f K R I S 136 5 The Risk V i e w 139 5.1 Project Risk Register 139 5.2 The Risk Profde 172 5.3 Standard Risk Register 183 5.4 Derivation o f the Project Risk Register Ut i l iz ing Content from the Standard Risk Register 187 6 Validation o f the Research 191 6.1 Model ing the Okanagan Lake Bridge and Sea to Sky Projects 193 6.2 Feedback from Industry Personnel 214 iv 7 Conclusions 216 7.1 Research Contributions 217 7.2 Limitations of the Approach and Suggestions for Future Research 221 Bibliography 224 Appendix A - Standard Risk and Environmental Views and Output Reports for the Okanagan Lake Bridge Case Study 238 A . l Standard Environmental Library 238 A . 2 Standard Risk Register 244 A.3 Master List o f Mitigation Measures 249 A . 4 Environmental V i e w - Okanagan Lake Bridge Project Case Study 251 A . 5 Risk V i e w - Okanagan Lake Bridge Project Case Study 281 Appendix B - Listing o f Data Files used in K R I S Implementation 292 B . 1 Files for the Risk V i e w 292 B . 2 Files for the Environmental V i e w 298 Appendix C - Summary o f Risk Categorization Schemes 303 C . l Categorized Listing o f Risks o f Construction Projects by Perry and Hayes (1985) 304 C.2 Categorized Listing of Risks o f Construction Projects by Kangari and Boyer(1987) 308 C.3 Categorized Listing o f Project Risks by Smith and Bohn (1999) 312 C.4 Risk Classification Framework by Arndt (2000) 313 C.5 Risk Breakdown Structure by Tah and Carr (2001) 314 C.6 Categorized Listing o f Financial Risks in Build-Operate-Transfer Projects by Xenidis and Angelides (2005) 315 Appendix D - Calculation o f Parameters for Risk Event Components 316 List of Tables Table 1. Knowledge management Tools Identified by Tyndale (2002) 32 Table 2. Knowledge management Tools Identified by Davenport and Volpe l (2001).. ..34 Table 3. Comparative analysis o f knowledge-based systems for risk management 48 vi List of Figures Figure 1. Project Phases of a F D B O M Project - The Viewpoint of the Public and Private Sectors 7 Figure 2. Rendering of the Proposed Okanagan Lake Bridge Reproduced with permission from Province o f Bri t ish Columbia (2005b) 12 Figure 3. Layout V i e w of Sea to Sky Highway Improvement Project Reproduced with permission from Province of British Columbia (2005a).... 14 Figure 4. Conceptual V i e w o f the Variation in Risk Transfer to the Private Sector between Alternate Project Delivery Modes 23 Figure 5. Conventional Procurement Mode - Government Viewpoint 25 Figure 6. F D B O M Procurement Mode - Government Viewpoint 26 Figure 7. F D B O M Procurement Mode - Private Sector Viewpoint 26 Figure 8. Comparison of Net Present Cost o f Alternative Procurement Methods 27 Figure 9. Distribution of the Net Present Cost for Alternate Modes o f Delivery 28 Figure 10. A Semantic Network 37 Figure 11. A Frame 39 Figure 12. Constituents o f the Project Context 54 Figure 13. Relationship between concepts 75 Figure 14. Spectrum o f Ontologies Identified by Lassila and McGuinness (2001) 78 Figure 15. Ontology Representation Techniques Identified by Goble and Shadbolt (2002) 78 Figure 16. Accumulation and Re-use of Information and Knowledge Related to a V i e w 80 Figure 17. Overview o f the Standards Side 83 vi i Figure 18. Overview o f the Project Side 84 Figure 19. Structuring of a V i e w as a Series of Templates 86 Figure 20. A Template Defined at the Environment Level of the E B S Hierarchy 100 Figure 21. A n Environmental Template Defined at the Class Level of the E B S Hierarchy 101 Figure 22. Editing the Environmental Component Hierarchy 102 Figure 23. Adding Environmental Templates 103 Figure 24. Master Environmental Breakdown Structure 105 Figure 25. Accessing Attributes o f Environmental Components 108 Figure 26. Details o f Attributes o f Environmental Components 110 Figure 27. Definition of Standard Attributes 112 Figure 28. Use of the Standard Set of Attributes in Defining Component Properties.... 113 Figure 29. Definition o f a Standard Set of Units 113 Figure 30. Associating Information Sources with Environmental Components 115 Figure 31. L ink ing o f E B S Records to Content Available in Electronic Form 116 Figure 32. Model ing the Risk Driver - Issue Relationship through Associations 118 Figure 33. Model ing Risk Issue Conditions 120 Figure 34. Specification o f Risk Issue Conditions 121 Figure 35. Example Use o f the Memo Field o f Environmental Components 122 Figure 36. Addit ion o f Components in Building up the Project Environmental Mode l 124 Figure 37. Definition of Locations for Okanagan Lake Bridge Project 126 Figure 38. Assigning Attribute Values to Components Present at Different Locations 127 Figure 39. Associating Project Records with Environmental Components 129 Figure 40. Partial Overview o f the Okanagan Lake Bridge Project Environmental Mode l 131 viii Figure 41. Use of Standard Components in Defining Environmental Model of the Sea to Sky Highway Project 133 Figure 42. Addit ion of Components in Building up the Project Risk Register 143 Figure 43. Descriptive Properties of Risk Components 146 Figure 44. Development of a List o f Project Phases 148 Figure 45. Risk Drivers Folder o f Project Risk Issue Components 149 Figure 46. Interface for Selection o f Drivers from the Project Environmental V i e w 150 Figure 47. Model ing o f Risk Driver Information for Project Risk Events 152 Figure 48. Evaluating the Status of Risk Conditions at a Location 155 Figure 49. Model ing o f Information and Knowledge Related to Performance Measures 157 Figure 50. Augmenting Lists o f Methods o f Incorporating Risks into Economic Analysis and Methods o f Estimating Likelihood / Consequence 160 Figure 51. Assigning Appropriate Mitigation Strategies to Risk Events on a Performance Measure Basis 162 Figure 52. Master List o f Mitigation Measures 163 Figure 53. Modeling the Project Parties Affected by Risk and Parties Best Suited to Manage the Risk Event 165 Figure 54. Probability Tree Corresponding to Outcomes o f Slope Failure Risk Event. 167 Figure 55. Assignment o f Probability Values for Scenarios 168 Figure 56. Model ing the Outcomes of a Risk Event 170 Figure 57. Differentiating Between Active and Inactive Risks within the Risk Profile 174 Figure 58. Filtering o f Inactive Risk Components o f the Project Risk Register 175 Figure 59. Representing the Change in the Risk Profile due to Underlying Changes in the Project Context 177 ix Figure 60. Selection o f a Subset of Risk Components as Targets o f the Reporting Function 179 Figure 61. Selection o f the Content of a Risk Report 180 Figure 62. Specification o f Select Conditions for Generating Risk Reports 181 Figure 63. Specification of Sort Conditions for Generating Risk Reports 182 Figure 64. Visualizing Distribution o f Risk Events across Phases and Responsibility. 183 Figure 65. The Standard Risk Register 186 Figure 66. Modes of deriving the Project Risk Register 187 Figure 67. Environmental V i e w o f the Okanagan Lake Bridge Project - Component Definitions o f Physical Environment (Ex. Zoological Components) 195 Figure 68. Environmental V i e w o f the Okanagan Lake Bridge Project - Definitions o f Zoological Components 196 Figure 69. Environmental V i e w o f the Okanagan Lake Bridge Project - Definitions o f Social, Economic, Political, and Regulatory Components 197 Figure 70. Definition o f Locations for Okanagan Lake Bridge Project 198 Figure 71. Physical V i e w o f the Okanagan Lake Bridge Project - Component Definitions 199 Figure 72. Process V i e w o f the Okanagan Lake Bridge Project - Overview 200 Figure 73. Process V i e w o f the Okanagan Lake Bridge Project - Act ivi ty Components o f Project Execution Phases 201 Figure 74. Organizational V i e w o f the Okanagan Lake Bridge Project - Component Definitions 202 Figure 75. Risk V i e w o f the Okanagan Lake Bridge Project - Categories and Sub-categories o f Risks 203 Figure 76. Risk V i e w o f the Okanagan Lake Bridge Project - Management and Organizational Risk Issues and Events 204 Figure 77. Risk V i e w of the Okanagan Lake Bridge Project - Polit ical, Economic, and Cultural / Stakeholder Risk Issues and Events under the External Risk category 205 Figure 78. Risk V i e w of the Okanagan Lake Bridge Project - Physical and Regulatory Risk Issues and Events under the External Risk category 206 Figure 79. Risk V i e w of the Okanagan Lake Bridge Project - Technological and Operational Risk Issues and Events 207 Figure 80. Standard Environmental Library - Components Defined in Addit ion to Components Identified on the O L B Project 209 Figure 81. Environmental V i e w o f the Sea to Sky Highway Project - Definitions o f Physical and Social Environmental Components 211 Figure 82. Environmental V i e w o f the Sea to Sky Highway Project - Definitions o f Economic, Polit ical, and Regulatory Environmental Components 212 Figure 83. Risk V i e w o f the Sea to Sky Highway Project - Risks Automatically Identified by System based on Definition of Environmental V i e w 213 Figure 84. Standard Environmental Library - Geological, Seismological, Climatological, Designated Area, Existing Building, and Existing Structures Components o f the Physical Environment 239 Figure 85. Standard Environmental Library - Road and Ra i l , Uti l i ty, Hydrographical, and Hypsographical Components o f the Physical Environment 240 Figure 86. Standard Environmental Library - Botanical Components and Birds 241 Figure 87. Standard Environmental Library - Mammals, Amphibians, Reptiles, and Fish Components 242 Figure 88. Standard Environmental Library - Social, Economic, Polit ical, and Regulatory Environmental Components 243 Figure 89. Standard Risk Register - Polit ical, Economic, and Cultural and Stakeholder Risk Issues and Events 244 xi Figure 90. Standard Risk Register - Physical Risk Components 245 Figure 91. Standard Risk Register - Operational Risk Components 246 Figure 92. Standard Risk Register - Design and Construction-related Risk Components 247 Figure 93. Standard Risk Register - Regulatory Risk Components 248 Figure 94. Selection Criteria Used for Generating Output Report 281 Figure 95. Overview o f M a i n Categories 304 Figure 96. Physical Risks Category 304 Figure 97. Construction Risks Category 305 Figure 98. Design, Political, and Financial Risk Categories 306 Figure 99. Legal & Contractual and Environmental Risk Categories 307 Figure 100. Overview o f M a i n Categories 308 Figure 101. Construction related Risks and Risks related to Physical Aspects 309 Figure 102. Contractual and Legal Risks and Risks related to Performance and Management 310 Figure 103. Risks related to General Economic Factors and Political and Public Risks 311 Figure 104. Categorization Scheme 312 Figure 105. Risk Classification Framework 313 Figure 106. Risk Breakdown Structure 314 Figure 107. Categorization Scheme 315 Figure 108. Risk Event - Probability Values 316 Figure 109. Risk Event - Impact Estimates and Calculated Parameters 317 xii Abbreviations C O S E W I C Committee On Status of Endangered Wildl i fe In Canada CPI Consumer Price Index D B F O Design B u i l d Finance Operate D S C R Debt Service Coverage Ratio E B S Environmental Breakdown Structure E I A Environmental Impact Assessment F D B O M Finance Design B u i l d Operate and Maintain H M Her Majesty's ERR Internal Rate o f Return IT Information Technology K M Knowledge Management K R I S information and Knowledge application and re-use in RISk management L C C Life Cycle Cost M C S Monte Carlo Simulation M E B S Master Environmental Breakdown Structure N P C Net Present Cost N P V Net Present Value O L B Okanagan Lake Bridge P3 Public Private Partnership P B C Partnerships Brit ish Columbia PFI Private Finance Initiative P M I Project Management Institute P R I M E Project R i sk knowledge Management Environment P R R Project Risk Register P S C Public Sector Comparator R A M P Risk Analysis and Management for Projects R E O I Request for Expressions O f Interest R F P Request For Proposals R O I Registration O f Interest S E L Standard Environmental Library S R R Standard Risk Register T R I M S Technical Risk Identification and Mitigation System xiii Acknowledgements Foremost, I would like to express my sincere gratitude to Prof. A l a n Russell whose ability to achieve the perfect balance between being demanding and empathetic towards his students continuously amazes me. I am immensely grateful for his guidance and encouragement throughout my life as a graduate student. M y thanks also go out to Professors Thomas Froese, Barbara Lence, and Scott Dunbar for serving on my Ph.D. committee and for their comments that helped make my thesis a much better one. I would like to thank Prof. Roger Flanagan for a very thoughtful review of the thesis in his role as the external examiner, and also to the university examiners Prof. T i m McDaniels and Prof. Sigi Stiemer for their constructive review o f my work. The pursuit of graduate studies has its ups and downs and having a set o f great friends to share both its rewards and frustrations helps immensely. A big thank you to He l i , Arezou, Tanzy, Paul, Justin, M i n g E n , Kehui , M i n , Dinesh, Arthur, Marina, Asad and David for all the fun times. I really think we contributed greatly to the success o f the coffee industry irrespective of how we may have helped science along. I am also indebted to Professors M a l i k Ranasinghe and Sam Hettiarachchi o f the University of Moratuwa and to Dr . Ziad Shawwash o f B C Hydro for their encouragement and advice at various stages o f my studies. Finally, words could never do full justice to the gratitude I feel towards my mother and late father and my wife Missara for all the sacrifices they made and for their unfailing support and belief in me. xiv Dedicated to the memory of my father and to the hope and joy that someone due later this year brings. xv 1 Introduction 1.1 Managing the Economic Risks of Infrastructure Projects Presently, governments on a worldwide basis are faced with an insatiable demand for public infrastructure such as roads, bridges, transit systems, water supply systems, and wastewater treatment plants. They wrestle with how to construct these facilities in the face of tight budgets and pressing needs for other services such as health and education. A s a result, governments are exploring a greater range of procurement modes in an effort to meet some o f the demands for new or improved infrastructure in a timely manner. Many of these modes can be grouped under the rubric of public-private partnerships, or P3's. O f particular interest are those modes (e.g., Finance, Design, Bui ld , Operate, and Maintain - F D B O M ) that maximize the involvement o f the private sector and which result in the greatest transfer o f risk to this sector. Major design and construction firms are embracing the challenge of such procurement modes, as they provide the opportunity to deliver value-added services and create new business opportunities. The recent emphasis on considering alternative modes of procurement for public infrastructure has resulted in governments taking a more disciplined approach to risk management, especially for major projects. For example, it is said that the rigour o f the risk assessment and contractual risk allocation processes undertaken for P3 projects in Victoria, Australia exceeds any risk evaluation process ever undertaken by an Australian government (Fitzgerald 2004). Private sector firms now find themselves assuming responsibility for all facets of the total life cycle o f a project, including financing, regulatory processes, design, construction, commissioning, revenue generation, operation and maintenance, and debt servicing. A s a result, they must identify and manage a much larger spectrum o f risks - in fact it is this extended risk transfer that has special appeal to government. Effective management o f project risks has the potential to bring about cost savings and other benefits. Andersen (2001) draws attention to a study carried out in Denmark which suggests that savings in the range of 800 mi l l ion euro could be achieved annually in the Danish construction industry through the introduction of formal project risk 1. management. A survey carried out by Voetsch (2003) o f more than 150 respondents from various industries such as information and communications, energy, and construction has indicated that a positive relationship exists between the frequency o f use o f formal risk management practices and the frequency o f project management success, as measured by customer satisfaction, on time project delivery, and avoidance o f the project being descoped 1. However, the scale and complexity o f infrastructure projects can present significant difficulties for risk management. The lengthy time spans o f the pre-financial close phase and the operational phase, the multitude o f stakeholders involved, coupled with requirements to carry out environmental studies and adopt protective measures, complicate an already complex task o f designing, constructing, and operating a facility that typically contains a vast number of components and an equally large number o f technical and administrative processes (Flanagan and Norman 1993). Therefore, the task o f identifying the risks associated with all facets of the project lifecycle, assessing their magnitude, and the development o f response strategies is non-trivial. In some instances the number of categories of risks such as design risk, project scope risk, native title, construction risk, commissioning risk, industrial relations risk etc. can run into over 100 (Fitzgerald 2004) with each category consisting o f several individual risk events. A s with other management functions, knowledge and experience are invaluable assets in successfully dealing with the risks of a project. Recognizing the risks that are relevant to a particular project, identifying their impact on project performance measures, and devising appropriate risk mitigation measures are all tasks which rely heavily on past exposure to similar situations. However, knowledge within organizations that resides primarily in the minds o f experienced personnel is seldom documented i n a consistent and accessible manner (Rezgui 2001), and can easily be lost through resignations, downsizing, and retirements. Computer-based methodologies that make use of advances in Information Technology (IT) have the potential to play a significant role in facilitating the capture of knowledge gained on past projects in a manner suitable for re-use. A s 1 A word that is yet to reach most dictionaries, "descope" refers to the reduction or elimination of elements of a project that can be accomplished, while still permitting the project to meet the critical project objectives. Source: N A S A (http://appl.nasa.gov/resources/crm/glossary.html) 2 identified by Fitzgerald (2004) in a study of P3 projects undertaken in Victoria, Australia, "the expertise of the risk evaluators and the comprehensiveness of the risk schedule does not substitute for the lack of an empirical database of what risk events major projects of this nature face and with what frequency and cost should they be expected\ Such methodologies also have the potential to assist users in exploiting project information and archived knowledge in effectively tackling project risks. Their use can help reduce the burden on the project team in identifying and managing all significant risks, and assist in avoiding costly omissions that could undermine project success. To date, a methodology that can deliver on this promise does not exist, although a number of researchers have sought to develop risk management tools using various IT approaches, (e.g., N i w a 1989, Tah and Carr 2001). While progress has been made in treating subsets of the risk management process, further success depends on developing an approach that treats several issues comprehensively and in unison. Among such issues is the need to explicitly consider the context under which risks occur and need to be managed, i.e., to treat the project context, and allow facility to users for capturing their knowledge in a reusable and editable format, features that are not fully addressed by current approaches. A n integration o f risk information with information describing the project context w i l l allow the user to identify and focus on context-specific risks as opposed to perusing a generic listing of risks made available by tools such as prompt lists. It could also assist in identifying changes in the risk profile that could accompany changes in other project information, especially when design changes are made, or as more project information is obtained. A matching o f risks to project context information could also facilitate knowledge re-use on future projects by allowing the identification o f recurring project conditions that act as drivers o f risks. A methodology also needs to be cognizant o f the realities of full-scale projects for it to be practical. These include the need to work at different levels of granularity of project definition as the project life cycle unfolds, the need to cope with vast amounts o f information, and the need to work with incomplete information. This thesis documents the development of a methodology that meets these broad requirements. The methodology is termed K R I S (an acronym for 'information and Knowledge application and re-use in R I S k management'). In the following section a 3. summary o f the specific research objectives is presented, followed by a commentary on the scope of the research endeavour. 1.2 Objectives and Contributions of the Research The management of risks necessarily involves their identification, quantification o f their impact upon performance measures, and the development and implementation o f risk response measures (Chapman and Ward 1997; Construction Industry Research and Information Association 1996). These risk management functions require the use o f a diverse set of information such as the conditions under which particular risk events occur, probability and consequence values o f the risks, details o f the mitigation measures that are applicable, and information regarding the project stakeholders affected by the risk. The broad objective of the research was to develop a methodology that facilitates the modeling and application of information and knowledge in managing the risks of an infrastructure project and which facilitates the re-use of such content on future projects. The specific research objectives that relate to this task are: • Identifying the core set of information and knowledge groups used in managing economic risks as wel l as the concepts that are applied in the process; • Developing a set of constructs that can be used within a computerized environment to model the information and knowledge related to risks as well as the aspects of the project context that are o f relevance to risk management; and, • Formalizing a methodology that allows representations of the risk-related information and knowledge to be generalized and stored in a project neutral format, and facilitates the extraction and use of the project-neutral representations in developing a model of the risk profile on future projects. K R I S meets these objectives, and i f applied correctly would move an organization closer to its prime goals in risk management, which are to minimize exposure to downside risks and maximize exposure to upside risks, or to minimize risk altogether. Whilst the ultimate contribution of K R I S to risk management practice is in facilitating an organization to better achieve these goals, its research contribution arises as a result o f 4 answering a series of questions and challenges that relate to both the intellectual and practical aspects o f the risk management domain. Broadly, the questions that need to be addressed by a computer-based methodology that aims to allow an organization to manage risk-related information and knowledge fall under several topics. They are: (i) Questions as to the most appropriate role(s) for the machine and for the system users in developing a computer-based methodology; (ii) Questions related to the representation of risks; (iii) Questions related to representing the project context-risk relationship and the representation of the project context; (iv) Issues dealing with leveraging such representations to maximize the assistance that can be provided to users to derive meaning from the models. For example, to support diagnosis such as the work activities that are most risk prone and the change in the risk profile that occurs as alternative activities are considered; and, (v) Questions relating the content that can be re-used for other projects and the means by which re-use can be facilitated. Each topic is made up o f a series o f questions and they are elaborated upon in Chapter 3. Current approaches have either implicitly or explicitly dealt with some of these questions. However, the treatment has been incomplete with regard to individual questions and no approach has attempted to deal with them in totality. The contribution of K R I S therefore is that it provides a means of addressing each o f these questions individually and more importantly o f addressing them in unison, a feature that provides users with unmatched capability o f modeling, re-using, and deriving meaning from the risk-related information and knowledge on infrastructure projects. 1.3 Research Scope and Anticipated User Audience The focus is on supporting the risk management function in c iv i l infrastructure projects, with the emphasis being on risks with economic consequences, i.e., risks that ultimately impact economic performance measures of a project such as total project cost and duration, Net Present Value ( N P V ) , Debt Service Coverage Ratio (DSCR) , and Internal 5. Rate o f Return (IRR). Whi le projects procured using alternate modes such as P3s are o f particular interest due to the greater emphasis placed on risk analysis, the application o f K R I S is not restricted to projects procured as P3s. It could also be utilized on projects procured using a traditional design-bid-build approach, albeit to model and manage information and knowledge related to a narrower realm of risks, particularly in the case o f private sector users whose role is limited in traditional delivery. The use of examples that have been drawn from P3 project scenarios in illustrating the research concepts does not therefore reflect limitations in applicability. In a similar vein, the application o f K R I S does not assume the use o f a particular risk management approach. A s w i l l be elaborated in Chapter 2, several approaches towards the risk management process have been proposed by various authors. A core set of information common to many of these approaches are modeled within K R I S making it broadly applicable. Risk management is a continuous process that is applied in a transforming manner throughout the lifecycle o f a project. The approach towards risk management along the timeline o f a project requires consideration o f the differences between the phases o f the project life cycle (Chapman and Ward 2003). The phases o f a F D B O M project from both public sector and private sector perspectives are shown in Figure 1. During the initial planning phase o f a project, risk management is geared towards supporting the government's go / no-go decision and decisions as to the scope o f the project, as wel l as providing input to validating the use of P3 as the preferred mode o f delivery. Alternatively, from a private sector perspective the primary role o f risk management during the early stages is to provide input to the private sector bids. In the succeeding contracting phase, the focus o f both the public and private sector is more on the use o f contractual risk transfer as a means o f risk mitigation. The project execution phases are characterized by implementation of risk mitigation measures to control the occurrence and the impact o f risk events. K R I S is aimed primarily towards supporting the planning, procurement, and the contracting phases o f a project, as these are the phases during which strategic decisions are made by both the public and private sector with critical input from the risk management process. Having said this, extensions can be readily made to the methodology to allow for the tracking o f risks during the course o f a project. 6 Publ i c Sector S-i <D MJ -UJ C 03 U P l a n n i n g / | P r o c u r e m e n t | N e g o t i a t i o n s S t r a t e g y J j .&. C o n t r a c t i n g d e v e l o p m e n t ' J C o n t r a c t : M a n a g e m e n t a n d M o n i t o r i n g u o ;' t C J P r o c u r e m e n t J ; N e g o t i a t i o n s F i n a n c i n g , D e s i g n , C o n s t r u c t i o n : , - . O p e r a t i o n , D e b t S e r v i c i n g e o i ' & C o n t r a c t i n g m in <D u c o u Private Sector Figure 1. Project Phases of a F D B O M Project - The Viewpoint of the Public and Private Sectors Data, information, and knowledge regarding the risks of a project are treated with varying degrees of confidentiality throughout the project lifecycle. In a P3 : project, the government w i l l treat values assigned to various project risks in its financial models as confidential in order to preserve competitive pressure (Partnerships Brit ish Columbia 2005b). Making known such value assignments w i l l result in the government being at a disadvantage as it negotiates the intricacies o f risk allocation with the private sector. The private sector for its part would strive to keep the mitigation strategies that could affect its risk profile and the value o f their bid confidential in order to achieve success during the bidding process, and in the event o f success, in negotiating a favourable apportionment of risks during the Best and Final Offer process (Akintoye et al. 2003). From a methodology development perspective, the implication o f such practices is that support for managing risk-related knowledge is best provided at the enterprise level, an assertion further strengthened when risk perception is taken into account. Different organizations and individuals tend to have different perceptions of the risks associated with a project (Gallimore et al. 1997). This can hold true in a comparison o f the private sector and the government sector, as well as in comparing different private 7. sector entities involved in the project delivery process such as general contractors, financiers, and facility operators. The difference between the risk perceptions of different parties can be as far apart as one party seeing an opportunity in an instance where another believes a downside risk to exist. Therefore, taking into account the issues of confidentiality of information and the potential differences in risk perceptions, K R I S has been developed for use within a single organization. Enterprises that serve as candidates for users include the government represented by individual ministries, and entities such as Partnerships British Columbia which is responsible for bringing together ministries, agencies and the private sector to develop projects through P3s (Partnerships British Columbia 2005a). Private sector entities such as engineering firms and lending institutions also stand to gain by utilizing a methodology such as K R I S that allows the re-use of risk-related information and knowledge on the different projects they undertake, especially P3 ventures in which they are faced with the task of managing a much larger spectrum o f risks. 1.4 The Research Path The author's thoughts first turned towards research on information and knowledge re-use in risk management as a result o f discussions between the author and his research supervisor during a period in which the author was completing a Masters thesis on environmental risks. During that research, it became obvious that while the topic o f risk management has seen extensive research interest over a period o f time, much work remains to be done in managing 2 the knowledge and information associated with the process. Also moulding the focus of the research was a renewed interest within the province o f British Columbia, Canada in alternative modes of infrastructure delivery. Whilst the arguments as to the pros and cons of such modes persist within the province and elsewhere, several such projects have got of f the ground in recent years. A s stated 2 A s w i l l be discussed in Chapter 2, a multitude o f definitions exist for terms such as 'knowledge management'. In the context o f the research described, 'managing information and knowledge' is used to col lect ively refer to the tasks o f developing the information and knowledge assets as an organization undertakes projects and applying such content in managing the risks o f individual projects. 8 previously, risk management is exceptionally significant on such projects, and the author's involvement in the probabilistic risk analysis of one of the projects in British Columbia and subsequent involvement with a short course on P3 projects for the Taiwanese government reiterated the practical significance o f the research. A s in most cases, the research itself started off with a thorough investigation of currently available approaches toward information and knowledge application and re-use within the context o f risk management. The investigation uncovered that while related research efforts have been focused on subsets o f the risk management process and on specific project types, a methodology that has wider applicability is yet to be proposed. Attention was also paid to advances in the field o f knowledge management, an area o f research that is comparatively young in relation to risk management, yet has much insight to offer in relation to the research topic. Once the boundaries of state of the art were identified, the research focused on identifying the specific requirements o f a methodology that can meet the objective o f enabling information and knowledge application and re-use. The requirements took into consideration the types o f information and knowledge that need to be modeled as wel l as issues of practical significance. Initially, the K R I S methodology was developed in conceptual form. The concept adopted relies on the development o f an enterprise-level ontology or library o f risks integrated with similar libraries that can be used to describe the context of a project. The conceptual formulation was followed by the implementation o f K R I S as a prototype computer system. The implementation was carried out within the RepCon research system used at the University o f British Columbia, making use o f some existing data structures while adding several others. Among the structures re-used were the implementations for representing the physical, process, and organizational dimensions o f projects. Structures for representing risks and the environment were developed in direct support of the methodology. Extensive testing o f the K R I S implementation making use of the details from two case studies was the concluding step o f the research. The testing also served in determining the validity o f the approach, by allowing the verification of its ability to model required information and knowledge as wel l as its ability to allow such information and knowledge to be re-used among different projects. 9 1.5 Structure of the Thesis The dissertation is organized into seven chapters including the current introductory chapter. In addition to the material already presented, the current chapter also details two case studies, one a floating bridge project and the other a highway improvement project, that are used in illustrating aspects o f the K R I S methodology. Structured approaches to risk management that have been suggested by various authors are examined in Chapter 2 which presents the state o f the art in managing risks in infrastructure projects. The topic of knowledge management is also studied with particular emphasis on tools available for managing information and knowledge generated during the risk management process. Among the methodologies scrutinized are risk categorization schemes, risk registers that serve as repositories o f project risk information, as wel l as knowledge-based tools for risk management. The state o f the art review sets the stage for Chapter 3 which presents an in depth analysis of the desired requirements o f an approach for enabling information and knowledge application and re-use in an infrastructure project, and the extent to which current approaches have met the requirements. Also presented in the chapter is a conceptual overview o f the proposed methodology, and a description of the rationale for selecting the particular approach that has been adopted in devising the methodology. It is asserted that integrating risk-related information with representations o f the project context can enhance the effectiveness of the risk management process and enable knowledge to be encoded in a reusable manner. In K R I S , representations of the physical, process, organizational / contractual, and environmental dimensions of projects are utilized in modeling the project context. Chapter 4 describes the modelling methodology in detail with examples being drawn from the characterization of the environmental dimension of the floating bridge project and the highway project that serve as the case studies. The structure o f a standard risk issue register that serves as a generic repository o f an organization's knowledge on risk, and a project risk register that is a project-specific model of risk issues is presented in Chapter 5. Modes o f developing a project risk register from the standard risk issue register utilizing the project context representations are also elaborated upon in the chapter. 10 The approach taken towards the validation of the research is presented in Chapter 6. Chapter 7, which is the concluding chapter o f the thesis presents a summary of the research contributions while identifying its limitations. It also presents recommendations for future research that could extend from the effort described in the thesis. The thesis also contains several appendices. Presented in Appendix A are the details o f a standard risk register as well as details o f the risk and environment models of the floating bridge case study. The details are presented primarily in the form o f output reports generated using the computer implementation of K R I S . Appendix B provides details o f the computer implementation, specifically a listing of the data files used and the functions served by each of the files. A sampling of risk categorization schemes suggested in the literature is presented in Appendix C . Finally, details o f calculations used in determining various statistical parameters of risk events are presented in Appendix D . 1.6 Case Studies In illustrating aspects o f the K R I S methodology, use is made o f examples from two rather distinct case studies, one a floating bridge construction project, and the other a highway improvement project that spans in excess o f 90 km. The environment o f the floating bridge project is tightly bounded (British Columbia Ministry of Transportation 2003b) whereas, the highway project traverses through several jurisdictions and through urban, coastal, and mountainous regions (British Columbia Ministry of Transportation 2004). Use o f two diverse case studies has allowed the ability of the methodology in allowing the re-use o f information and knowledge gained on one project on another to be assessed. Information presented about the case studies has been derived from public domain documents and represents the author's interpretation o f information contained within these documents. A description of the two projects follows. 1.6.1 Okanagan Lake Bridge Proj ect The three-lane Okanagan Lake floating Bridge ( O L B ) on Highway 97 is one o f Brit ish Columbia's most congested sections o f highway having been in service for 46 years 11 (Province o f Brit ish Columbia 2005b). It is a vital link in the region's transportation system as it is the only bridge to cross Lake Okanagan. The Province of British Columbia has sought a private sector entity to design, build, finance, maintain, and operate a new five-lane crossing 3 (see Figure 2), while operating, maintaining, and then decommissioning the existing 880m long bridge. The private sector w i l l also be responsible for operating and maintaining associated roadworks on the west side o f the lake as part o f the development that has an estimated total capital cost of $145 mil l ion. L...Z. Figure 2. Rendering o f the Proposed Okanagan Lake Bridge Reproduced with permission from Province of Brit ish Columbia (2005b) The initial Request for Expressions O f Interest (REOI) was released by the government in February, 2003. It is expected that the new crossing w i l l be open to traffic in the spring of 2008, with no tolls being levied on users. The private sector w i l l be compensated through a series o f performance payments during both the original service period in which the new crossing is designed and built while keeping the original crossing in 3 The new crossing has been officially named as the William. R. Bennett bridge. 12 operation, as well as in the enhanced service period during which the new crossing is operated. The performance payments take into account factors such as availability o f the crossing, traffic volume, safety, and customer satisfaction. The term of the concession agreement would be either 30 or 40 years depending upon the proposal that is selected by the province (Province o f British Columbia 2004a). Issues of significance from a risk perspective on the O L B project includes the rarity o f floating bridges in the world which has led to a lack of design standards, as well as a lack of personnel experienced in the dismantling, design, and construction of such structures. The lack of a viable alternate route that leads to requirements to keep the traffic disruptions to a minimum can also present challenges. The possibility of unearthing archaeological artifacts is a primary concern on the west side of the lake, with two unexamined archaeological resource areas being present in the area. 1.6.2 Sea to Sky Highway Improvement Project The Sea to Sky highway improvement project in British Columbia (Province of British Columbia 2005a) serves as the second case study. The project involves widening and straightening a 94.7 k m section of highway in a mountainous and environmentally sensitive area. The expansion involves five road sections including bridges and viaducts. M o v i n g south to north (see Figure 3), the configuration consists of a 12.2 km four-lane section between Horseshoe Bay and Lions Bay, a 10.5 k m two-lane section between Lions Bay and Porteau Cove, a 19.7 km three-lane section between Porteau Cove and Squamish, a 9.9 k m four-lane section within urban Squamish, and a 42.4 km three-lane section from Squamish to Whistler. The Province o f British Columbia's Request for Proposals (RFP) calls on the private sector entity to (i) design and construct the improvements to the highway, (ii) maintain, operate and rehabilitate the improved highway, and (iii) finance the design, construction, maintenance, operation, and rehabilitation (Province o f British Columbia 2004b). The total capital cost o f development is estimated to be $600 mil l ion. 13 Figure 3. Layout V i e w o f Sea to Sky Highway Improvement Project Reproduced with permission from Province of Brit ish Columbia (2005a) 14 A n initial Registration of Interest (ROI) process was initiated by the government in February, 2004, with a targeted date of completion of the improvements being late 2009, in time for the Winter Olympics scheduled to be held in 2010 in Whistler and Vancouver. Similar to the Okanagan Bridge project, it is anticipated that no tolls w i l l be levied on users. The private sector w i l l be compensated through a series o f performance payments during the project term that lasts until the Design, Bu i ld , Finance, and Operate ( D B F O ) agreement termination date of March 31, 2030. The performance payments take into account factors such as availability of the highway, meeting the traffic management plan during construction, traffic volume, and safety record. Issues o f significance from a risk perspective on the Sea to Sky project includes potential damage to the natural environment through which the highway traverses. Among the sites o f concern are a number o f water bodies, specifically, 67 roadside drainage ditches, 191 creeks and streams, seven lakes, one pond, 24 wetlands, and one estuarine tidal marsh that the road sections cross. The highway also passes through several municipalities that have different bylaws regarding construction, traffic management, etc. The municipalities profess varying degrees of support for the proposed improvements including vocal opposition in some instances (Cornwall 2004)- Additional challenges are posed by the desire to minimize the number o f scheduled road closures during the construction phase. 15. 2 State of the Art of Risk Management and Knowledge Management This chapter starts with an analysis o f the risk management process with emphasis on its application in P3 projects. The analysis aims to provide an overview of the domain to which the K R I S methodology applies. In doing so, the different stages o f risk management are described, along with the tools that are available to support each stage. A s described in the previous chapter, K R I S is focused on supporting risk management during the initial phases o f the project when decisions are made as to the procurement mode and risk ownership. The implication of risk on the decision making process is described with emphasis on its impact on economic models o f the project. The discussion on risk management is followed by a discussion on the subject area o f knowledge management, which has seen extensive research interest in recent years. Knowledge management is a broad topic and the intent of the overview has been to put the current research in perspective. The use of IT in knowledge management is also discussed, while knowledge representation methods are identified with the aim o f determining their suitability for representing risk-related knowledge. The chapter concludes with an overview o f the state of the art in managing risk-related knowledge, including an analysis o f several research efforts aimed at developing knowledge-based systems. 2.1 The R i s k Management Process Risks are inherent in most i f not all infrastructure projects, and can be defined as uncertain events or conditions that, i f they occur, have positive or negative effects on a project objective (Project Management Institute 2000). Traditionally, project risks have been managed instinctively with risks remaining implicit (Construction Industry Research and Information Association 1996). However, the increasing complexity o f projects and regulatory requirements that necessitate a formal approach to risk (Chapman and Ward 1997) have created a need for an alternative approach. Thus, a number o f frameworks that aim to bring structure and discipline to the process of risk management 16 have been suggested in the literature. A methodical approach as suggested by these frameworks can assist in better identifying and assessing the risks that are relevant to a project, in focusing on the major risks for the project, and in making informed decisions regarding the control and mitigation o f these risks (Construction Industry Research and Information Association 1996). A project risk management framework proposed by Chapman and Ward (2003) consists of nine phases, with each phase being associated with a broadly defined deliverable. The phases are: i . Define - Relevant information about the project is consolidated with a view o f obtaining a clear, unambiguous, shared understanding o f all key aspects o f the project. i i . Focus - Preparation o f a strategic plan for the risk management process at an operational level. i i i . Identify - Identifying the sources o f risk and appropriate responses as well as the possible faults that lie in the responses. iv. Structure - Structure earlier phases and test simplifying assumptions. v. Ownership - Allocation o f responsibilities. v i . Estimate - Obtaining a basis for understanding which risks and responses are important, and estimating risk impacts in numeric terms. v i i . Evaluate - Synthesis and evaluation of the results of the estimate phase. v i i i . Plan - Producing a detailed action plan incorporating preventive and reactive responses to risks. ix. Manage - Monitoring, controlling and developing plans for immediate implementation. The Institution of C i v i l Engineers and the Faculty and Institute o f Actuaries (1998) have also developed a structured approach to risk management. The process is termed R A M P , an acronym for Risk Analysis and Management for Projects and has the objective o f providing a comprehensive and systematic process for identifying, evaluating and managing risk during the entire life cycle o f capital investment projects. R A M P includes a Risk Review stage during which risks are identified and entered into a risk register. 17 Next, the risks are evaluated to determine their likelihood and magnitude. Mitigation measures are then identified to avoid, reduce, or transfer risks. The Management stage that follows involves implementing the risk mitigating strategy and risk response plan developed during the Risk Review stage. The Construction Industry Research and Information Association (1996) of the United Kingdom has identified a ten-step risk management process. The steps are: • Identify objective o f the assessment. • Identify hazards and risks. • Assess risks (likelihood and consequences). • Identify mitigation actions. • Assess residual risks. • Estimate cost of mitigation. • Estimate cost benefit o f mitigation. • Consider ownership of risks. • Select and implement beneficial mitigation actions. • Monitor and repeat process. Similarly, Risk management planning, Risk identification, Qualitative risk analysis, Quantitative risk analysis, Risk response planning, and Risk monitoring and control form the crux of the risk management process suggested by the Project Management Institute (2000). Whi le the different risk management approaches described above consider the risk management process at varying degrees o f detail and describe tasks using different terminology, several core elements that are common to all the approaches can be identified. They are: (i) Risk Identification; (ii) Risk Quantification; and (iii) Risk Response. O f these, risk identification can be considered as the most critical step of the risk management process as unidentified risks can wreak havoc with the success of a project, as one is forced into a reactive mode, as opposed to a proactive mode, should the risks occur. 18 2.1.1 Risk Identification The risks that need to be detected during the risk identification process can be wide ranging. They can be grouped under several categories such as financial, economic, environmental, technical, political, stakeholder, and organizational/contractual risks. Identification o f the risks o f a project can be a significant challenge and depends heavily upon experience and knowledge gained from past projects. Presently, the methods available for identifying risks include brainstorming, the use o f checklists and prompt lists, the use of surveys, questionnaires and structured interviews, literature reviews, and the use o f expert systems (Akintoye et al. 2001; P M I Standards Committee 1996). In addition to the information contained within the tools themselves such as a listing of risks within prompt lists, details of the project and its environment serve as input to these methodologies. Brainstorming involves gathering together a group o f project personnel and external experts in order to elicit the risks that they feel could impact the project (Raftery 1994; Vose 2000). Participants are encouraged to discuss risks ranging from the obvious to ones that may seem outlandish at first glance in order to build up an exhaustive listing o f risks. The disadvantages involved with brainstorming include potential difficulties in accessing and assembling a group of personnel with sufficient knowledge and experience, and in ensuring that the personality traits of individuals do not impede the creativity of the group. It is noted that approaches such as the Delphi method (Wright and Ayton 1987) have been proposed with the aim of overcoming the latter disadvantage. Prompt lists are documents that provide a set of risk categories, while checklists are a series o f questions that could be presented to project personnel in order to determine the possibility o f a risk (Vose 2000). These lists could be pertinent to a particular type of project, or be listings that are general in nature. Prompt lists and checklists are intended to focus attention on a particular risk type, while the actual identification o f risks relies on the judgement o f the user. Similarly, surveys and risk-oriented interviews also attempt to tap into the experience and knowledge o f personnel in identifying risks. They involve asking a set o f open questions from a specialist in a particular subject area, with the aim of eliciting risks that could potentially affect the project (Construction Industry Research and Information Association 1996). 19 Most, i f not al l , o f the methods described above rely on the knowledge of project team members and external specialists in identifying project specific risks. This has led to several research efforts aimed at developing expert systems for risk identification. Among these are an intelligent risk identification system developed by Ashley and Perng (1987) and an expert system developed for identifying the risks of extra high voltage transmission line projects (Leung et al. 1998). The narrow domains to which they apply can be considered as a disadvantage of these rule-based systems. The goal in applying any one or a combination o f the methods described above is to arrive at a comprehensive list o f the sources of risks and potential risk events of a project ( P M I Standards Committee 1996), information on which is carried over to the risk quantification and response phases. 2.1.2 Risk Quantification Monte Carlo Simulation ( M C S ) , moment-based methods, and methods based on fuzzy-logic are among the techniques that are available for the quantification of risks. These methodologies work at different levels of accuracy and detail, and require varying types o f input such as probabilistic parameters and linguistic input. Risk quantification takes into account both the possibility o f risk events as wel l their consequences, and can be used to provide a measure of the risk inherent in individual work packages or o f the project as a whole. The outputs o f the quantification stage can assist in risk prioritization and in making decisions regarding risk response measures. O f the methods available for risk quantification, M C S can be considered as the most popular. Its simplicity and the ease with which it can be integrated into a spreadsheet representation o f the project cash flows utilizing software such as @Risk (Palisade Corporation 2005) and Crystal B a l l (Decisioneering Inc. 2005) have contributed to its popularity. M C S relies on input variables being defined as probability distributions. The rank correlation coefficients among the input variables are also required, or alternatively an assumption o f zero correlation. Samples taken from the input variables are used in determining the distribution o f a decision variable that is functionally related to the input variables. 20 Moment based methods (Ranasinghe 1990) involve the determination of probability parameters that describe the uncertainty o f a decision variable, taking parameters of the underlying base variables as input. The simplest analytical approach is to use the mean and variance of the primary variables in calculating the first two moments of the target variable. Refined approaches that make use of the first four moments have also been suggested (Kottas and Lau 1982). In addition to moments o f the inputs, the correlation coefficients between the input variables need to be specified. Both moment-based methods and M C S generally depend upon estimates elicited from experts, a practice made common due to the absence of actuarial data that can be used in describing the behaviour of input variables. The effort required to estimate multiple input parameters can be a barrier to the use o f such methods (McCabe 2003). A qualitative characterization o f likelihood and consequence using labels such as high, medium, and low serve as input to a fuzzy logic-based approached to risk quantification (Kangari and Boyer 1987). Fuzzy set theory can enable the composition o f fuzzy input variables into a single descriptor such as the total risk of a project. The use of linguistic input allows project personnel and other specialists to express their perceptions regarding project risk in natural language terms, and is considered the primary advantage o f a fuzzy logic-based approach. 2.1.3 Risk Response Risk response involves the development of risk mitigation measures and implementing them on an ongoing basis throughout the project life cycle. The mitigation measures attempt to ameliorate either the possibility of the risk or its consequences, or both the consequence and the possibility, in order to control undesirable deviations in the values of project performance measures. Mitigatory tactics can be wide ranging. They include attempts to reduce or eliminate the risk through measures such as use o f alternative materials and methods, better labour relations policies to minimize work stoppages, and training of staff in order to avoid hazards (The Institution o f C i v i l Engineers and the Faculty and Institute of Actuaries 1998). The transfer o f risk, in principle to the party best suited to manage the risk, is 21 another form of risk mitigation that is frequently adopted. Stakeholders may also attempt to avoid risks using measures such as the adoption of a familiar construction method instead o f an innovative one. The development of contingency plans to be executed should risk events occur is another form o f mitigation, and is aimed at reducing the consequences of risk events. It is also noted that project stakeholders might simply decide to absorb certain risks in instances where risks cannot be avoided or transferred. The impact o f absorbing risks can however be reduced by pooling them through the use of organizational structures such as joint ventures and partnerships. In the case o f most risks, selecting the best mitigatory action from several options is required (Project Management Institute 2000), with stakeholder risk tolerances serving as input to the decision along with the options available. 2.2 Risk Management in the P3 Context The risk management process holds special significance for infrastructure projects undertaken using alternative procurement modes such as P3s. The leeway provided in allowing a significant transfer o f risk to the private sector is an oft cited advantage of P3s (The Treasury Taskforce Limited 2000), along with other factors such as the additional opportunities afforded for harnessing the innovative abilities and efficiencies o f the private sector (Construction Industry Council 2000; De Zoysa et al. 2004). Shown in Figure 4 is a conceptual view o f the variation in risk transfer among a selection o f alternative modes such as design-build, design-build-operate, and build-operate-transfer modes. A s one moves from the left to the right o f the spectrum, the private sector is entrusted with responsibility for a greater number o f project phases, as wel l as the risks associated with the phases. Thus, from the perspective o f a private sector organization, they are faced with the tasks o f identifying the greater range o f risks that they would be taking on in comparison to the risks undertaken under a traditional design-bid-build mode o f procurement. The private sector is also faced with making decisions as to the pricing o f risks in responding to Requests For Proposals (RFPs) issued by the government, and devising responses to the risks that they would take on given that their bid is successful. 22 Degree of Risk Transfer Complete Traditional Operation;&: Design- Maintenance Bid-Build contract Design Build Major Maintenance Design Build Operate Build Lease Operate Transfer Finance Design Build Transfer Operate Finance Design Build Operate: Transfer •3> Delivery Mode Figure 4. Conceptual V i e w of the Variation in Risk Transfer to the Private Sector between Alternate Project Delivery Modes Alternatively, given a project context, government needs a methodology to assist it in assessing how best to procure the project from a procurement tool kit that ranges from traditional government-led project delivery through to complete private sector delivery in which government is limited to a regulatory oversight role. Having selected a procurement mode, government must make decisions as to the allocation of risks that would optimize value for money. A s public procurement involves the expenditure o f taxpayer's money, there is a constant need to ensure that the money has been spent economically, efficiently, and effectively. Where it can be expressed that taxpayer's money has been spent in this manner, it is concluded that value for money has been achieved. Value for money is optimized when program needs are met through the lowest combination o f capital, operating, and maintenance costs over the life of a project (British Columbia Ministry of Employment and Investment 1998). In theory, the evidence that value for money has been achieved is normally provided through the use o f a comparator (Ball et al. 2000; H M Treasury 1998). 23 2.2.1 Public Sector Comparator To date, a number o f authors and government bodies (Gaffhey et al. 1999; H M Treasury 1998; Illidge and C i c m i l 2000; Industry Canada 2002; Partnerships Victoria 2001) have written about the formulation of a Public Sector Comparator (PSC). The National Audit Office (2000) of the United Kingdom defines a P S C as follows: "A public sector comparator is a benchmark against which value for money is assessed. It is typically a cost estimate based on the assumption that assets are acquired through conventional funding and that the procurer retains significant managerial responsibility and exposure to risk. " Development o f a P S C is discussed in some detail by H M Treasury (1999), who defines it as "a hypothetical risk-adjusted costing by public sector to an output specification produced as part of a PFI4 procurement exercise ", in which costs have to be expressed in net present value terms based on recent actual public sector methods of providing that output, and take full account of the risks that would be encountered by that style o f procurement. It is emphasized by H M Treasury that "to be a valid benchmark against which private sector bids can be compared fairly, the PSC must reflect not only certain procurement costs but also the risk that additional costs may arise, which under PFI would fall to the supplier. During the procurement process, risks should be identified, and ways in which these risks can be mitigated considered. It is necessary to assess the impact of these risks on costs, estimate their probabilities, and explore and appreciate the sensitivity of these estimates. In many cases, adjustments to the original cost estimates will be needed to arrive at the final risk adjusted PSC. Comprehensive accounting for risk is required to ensure that valid and informed comparisons can be made amongst the bids and between the bids and the PSC. " The construction of the P S C can be illustrated by considering the government's cash flow profile for a generic infrastructure project that consists o f a design phase, construction of the facility, a revenue generating phase, and the operation and 4 PFI is an acronym for the Private Finance Initiative. The PFI was launched in the United K i n g d o m as a policy mechanism to obtain private finance for infrastructure investment. Whi le commonly used interchangeably with P3, PFI is more accurately portrayed as a subset o f P3, which can also include partnerships between the public and private sectors that are not necessarily driven by a policy initiative. 24 maintenance of the facility. The generic cash flow diagram shown in Figure 5 that depicts such phases is representative of most projects undertaken as P3s including tolled highways and bridges, water and wastewater treatment plants, and hospitals. 0 ^ Timr> rtnw Project financing ^Revenue • -Design /approvals/ tendering^ Operation & Maintenance Construction ' t Debt servicing Project management, legal insurance marketing, etc Management of facility Figure 5. Conventional Procurement Mode - Government Viewpoint In drawing the cash flows, the base costs as wel l as the risks associated with them have been aggregated. According to the definitions introduced above, solving for the Net Present Cost ( N P C ) 5 based on the government's rate of return would result in the P S C value against which alternative modes o f delivery would be evaluated. In adopting a mode such as F D B O M the government's cash flows would be significantly simplified and correspond to Figure 6, whereas the private sector viewpoint would be as shown in Figure 7. A comparison of the N P C o f the government's cash flows in adopting the P3 approach ( F D B O M in this example), with the P S C value obtained previously serves to aid the government in its decision making process as to the mode that should be adopted in procuring the infrastructure. It is also noted that central to the concept o f a P S C is a comparison of like things, and a facility that has the same scope and quality o f services should be considered in both scenarios. 5 N P C is used synonymously with N P V in the literature, with the term N P C being used especially in instances where it is obvious that the net value is a cost. 25 Time now 0 RFP/Negobate - Revenue'subsidy payment - ' . Time / > ^  Retained risks Oversight of facility & retained risks Project management, legal, etc'' Figure 6. F D B O M Procurement Mode - Government Viewpoint , Time now 0 Project financing Revenue subsidy from government. Revenue from operations RFP/Negotiate Design / approvals Construction Project management, legal.'insurance, marketing, etc Operation & Maintenance Debt servicing Management of facility Time Figure 7. F D B O M Procurement Mode - Private Sector Viewpoint In migrating from a traditional mode of delivery to a F D B O M approach, the composition o f the N P C from the government's viewpoint undergoes a transformation as shown in Figure 8. Each N P C consists of a base value obtained by the summation o f the base components of each cash flow, as well as summation of the N P C of the risk allowances in each cash flow. It is noted that while the base components could be higher in the case o f the F D B O M approach, the lower risk profile of such an approach from the government's perspective could result in an overall N P C that is lower than that of a traditional approach. 26 Retained Risks Risks Cost of service payments Base cost + Management costs Traditional mode P3 mode of of procurement procurement Figure 8. Comparison o f Net Present Cost of Alternative Procurement Methods Further insights may be obtained by considering the variability that is inherent in the N P C values. The inclusion o f the risks of each project phase within their individual cash flows results i n a N P C that is a distribution rather than a single number. Thus, i f a method such as M C S is applied i n analysing the uncertainty o f the N P C , the high degree o f risk inherent in the N P C o f the traditional delivery mode would result in a distribution that encompasses a wider range o f values in comparison with the F D B O M option. The N P C of the F D B O M delivery tends to be much tighter as a result o f its smaller risk profile, resulting in the maximum downside risk of the government being bounded as shown in Figure 9. Therefore even in instances where the mean N P C values may themselves be approximately equal, a comparison o f the N P C distribution can provide a compelling argument in favour o f a P3 approach. 27 Figure 9. Distribution of the Net Present Cost for Alternate Modes of Delivery The foregoing introduction to the risk management process illustrates that risk plays an important role in the project decision making process. However, the body of knowledge regarding project risk analysis and management is not coherent, and in its current state provides somewhat o f a confusing picture (AbouRizk 2000). In a similar vein, risk-related knowledge is generally distributed and poorly organized within project organizations (Andersen 2001). The following section reviews general approaches that have been adopted for managing knowledge within organizations, followed by a synthesis of the methods specifically devoted towards managing risk-related data, information, and knowledge. 2.3 Knowledge and its Management Many researchers have attempted to define knowledge, as wel l as distinguish it from data and information. Davenport and Prusak (1998) define Data as a set of discrete, objective facts about events, and Information as a message that is meant to impact on the judgement and behaviour o f the receiver. Knowledge is defined as "a fluid mix of framed 28 experience, values, contextual information, and expert insight that provides a framework for evaluating and incorporating new experiences and information". Nonaka and Takeuchi (1995) in their work on knowledge management within Japanese companies have also characterized Information as a flow o f meaningful messages, while defining Knowledge as commitments and beliefs created from these messages. Choo et al. (2000) identify Data as being facts and messages. Information is defined as data vested with meaning, and Knowledge is defined as justified, true beliefs. A synthesis of several such varying definitions is provided by Stenmark (2001). Knowledge itself is generally categorised into tacit and explicit knowledge (Bollinger and Smith 2001; Nonaka and Takeuchi 1995; Tiwana 2002), while some authors have gone further and introduced into a third category termed as cultural knowledge (Choo et al. 2000). The implicit knowledge that resides in individuals in forms such as intuition is defined as tacit knowledge, whereas explicit knowledge is such that it can be expressed and codified in a systematic and formal language. Cultural knowledge refers to the assumptions and beliefs that are used to describe and explain reality, as wel l as the conventions and expectations that are used to assign value and significance to new information. A s is the case with the multitude of definitions for knowledge, several definitions of Knowledge Management ( K M ) have also been suggested in the literature. A m o n g the definitions is one proposed by Davenport and Prusak (1998) that states: "Knowledge management is concerned with the exploitation and development of the knowledge assets of an organization with a view to furthering the organization's objectives". However, a general approach to the relatively new concept o f K M has not been commonly defined nor accepted (Bollinger and Smith 2001; Kakabadse et al. 2003). Kakabadse et al. (2003) have categorized these differing perspectives on K M into five groups, and discussed the role of Information Technology (IT) within each of the groups. The groups are: i . Philosophy-based model - Is mainly concerned with the epistemology o f knowledge and at creating an understanding o f the knowledge that resides within an organization. IT tools have little relevance in this model. 29 i i . Cognitive model - Knowledge is treated as an asset similar to land, equipment etc., and the focus is on its capture and storage. The codification, storage, retrieval, and transfer of knowledge in support of this approach are heavily dependent on IT. i i i . Network model - Perceives K M as a collaboration that requires networking. IT tools are seen as complementary facilities providing access to other knowledge and / or databases. iv. Community o f practice model - Based on the theory that knowledge is constructed socially and based on experience. Participation in a communal manner allows knowledge o f participants to be used as a pooled resource. IT can only be an integrative mechanism. v. Quantum model - A n emerging paradigm that is highly dependent on quantum computing and assumes that most intellectual work w i l l be performed by IT-based tools. In a similar vein, Tsui (2000) discusses three dominant streams of research into K M . The first stream deals mainly with theory o f knowledge, knowledge o f the firm, organizational culture, measurement o f intellectual capital and learning organizations. The second stream represents work on organizational memory and organizational memory information systems. It has a strong focus on knowledge sharing and on practical applications of K M . The third stream that has an IT-based perspective focuses on the areas of intelligent agents, ontologies, data mining, knowledge modelling, and computer-mediated collaborations. The abundance o f definitions o f knowledge and knowledge management makes it unsurprising that the processes suggested as being a necessary part of a K M strategy within an organization differ widely among different approaches. Ruggles (1998) suggests eight major knowledge-focused activities which are: • Generating new knowledge; • Accessing knowledge from external sources; • Representing knowledge in documents, databases, software and so forth; • Embedding knowledge in processes, products, or services; • Transferring existing knowledge around an organisation; 30 • Using accessible knowledge in decision making; • Facilitating knowledge growth through culture and incentives; and • Measuring the value o f knowledge assets and the impact o f knowledge management. Davenport and Volpel (2001) identify Create, Capture / Store, Refine, Distribute, Use, and Monitor as constituents o f the K M process, and discuss the types of K M projects undertaken by organizations to support the processes. Implementation of knowledge repositories has been found to be one of the more common projects in a study sample of 31 projects. Capturing knowledge for later and broader access is the primary objective in such instances, with the domain being restricted to a particular business function such as sales. A few K M projects have been found to focus on facilitating knowledge transfer. Technologies such as videoconferencing have been utilized in such instances. Management of knowledge assets such as the effective harvesting o f patent revenues has been identified as another type o f K M project undertaken by organizations. Some firms have also attempted to improve the overall environment for managing knowledge. Motivating employees to share or use knowledge to a greater degree, and increasing awareness on the importance o f knowledge are some of the tasks that pertain to this type o f project. A s illustrated by the preceding discussion, effective knowledge management typically requires a combination o f organizational, social, technological, and managerial initiatives, an assertion also made by others (Lindvall et al. 2003). The use of IT is therefore only a segment, albeit an important one, of a larger strategy that is required to manage knowledge within an organization. In the following section, a review of the use o f information technology tools in knowledge management is presented. 2.4 Use of Information Technology in Knowledge Management A variety o f IT tools that support various functions o f K M such as encoding, searching, organizing, and distribution o f knowledge exist. Several such technologies have been summarized by Egbu et al. (2004), while Tyndale (2002) has examined IT tools that have been specifically designed for the purpose o f K M , as wel l as established IT tools that 31 have been borrowed from other disciplines for the purpose o f K M . Sixteen such categories of technologies have been identified and are summarized in Table 1. Table 1 - Knowledge management Tools Identified by Tyndale (2002) Technology Description K M functions supported Intranets Company-wide information distribution system that uses Internet tools and technology. Knowledge transfer by allowing distribution of documents and other software files, and providing front end to company databases. Web portals A website providing links to other sites that can be accessed directly, or which can be found by following an organized sequence of related categories. Accessing knowledge from external sources. Content management Personalization functions that can be applied to Intranets, Web portals, databases, and file server, to provide easy access to desired subsets of content, as well as to obtain alerts on updates to the content. Knowledge transfer, and access. Document management systems A document store that provides functionality such as access control, and document searches on content and index terms. Representing knowledge and transferring it among users. Information retrieval engines Used for indexing, searching, and recalling data, particularly text or other unstructured forms. Allows use to be made of existing knowledge. Relational and object databases A store of information. Storage. Electronic publishing systems Distribution of information in digital format. Knowledge transfer and access. Groupware and workflow systems Groupware technology facilitates communication, coordination, and problem solving among a group of people. Workflow technologies deliver work items to appropriate users and allow tracking of the work items progress. Knowledge transfer, using accessible knowledge in decision making. 32 Table 1. (continued) Technology Description KM functions supported Push technologies Facilitates the sending of relevant information to users without the need for user intervention. Knowledge transfer. Agents Software that is autonomous, intelligent, collaborative, and adaptive. Can be used in information gathering and filtering, and in resolving inconsistencies. Generating new knowledge and embedding knowledge in processes. Help-desk applications Provide a single, shared database for logging helpdesk issues, notifying support personnel, and tracking problem resolution. Using accessible knowledge Customer relationship management (CRM) C R M technology allows a seamless front office to back office integration. Using accessible knowledge Data warehousing A central store of information common to the organization. It contains information drawn from disparate and physically distributed operational source systems of an enterprise, as well as external data. Storage. Data mining Process of selecting, exploring, and modeling large amounts of data to uncover previously unknown patterns. Generating new knowledge. Business process re-engineering Critical analysis and re-design of business processes. Embedding knowledge in processes, products, or services. Knowledge creation applications Brainstorming applications, concept mapping applications, decision support applications. Generating new knowledge and using accessible knowledge in decision making. 33 Davenport and Volpe l (2001) have identified 3 types of technologies that can assist K M . These technologies are described in Table 2. Table 2 - Knowledge management Tools Identified by Davenport and Volpe l (2001) Technology Description K M functions supported Repository and Access Technology Allow building repositories of codified knowledge and allow users to search. Built upon technologies such as Lotus Notes and Intranets, and supplemented with document management tools, search engines, and tools for managing and capturing expert biographies. Representing and accessing knowledge, transferring existing knowledge around organizations, and making knowledge available for decision making. Structured Knowledge Representation Tools Rule-based and case-based systems that are used to capture and provide access to knowledge. Representing knowledge and making it available for decision making. Knowledge Management E-commerce Tools Tools that allow distribution of knowledge over private and public networks. User can customize knowledge available and carry out sales transactions for knowledge purchases. Accessing knowledge from external sources and transferring knowledge around an organization. The preceding discussion on knowledge, its management, and the associated toolkit serves two functions. Initially, it is used to arrive at working definitions for data, information, and knowledge, as wel l as for knowledge management in the context o f the application domain o f K R I S . The definitions for data and information have been rehashed from definitions suggested by Davenport and Prusak (1998), with the definitions suggested by Choo et al. (2000) being used to add a simplifying flavour. The objective has not been to add another set o f definitions to an already crowded set, but to arrive at a set o f definitions that best fit the context. The definitions given by Davenport and Prusak (1998) have been selected due to their widespread use in the literature. Therefore, for use in this thesis, Data is defined as a set o f discrete, objective facts about events, whereas 34 Information is defined as data structured in a meaningful manner. Knowledge is defined as the mixture of framed experience, contextual information, and expert insight. In considering examples for the above definitions from the domain of risk management in infrastructure projects, a piece of data could be the string 'Examine usage history of worksite', whereas when listed under a master list o f mitigation measures and grouped along with other pieces of data such as 'Carry out geotechnical investigations', such that the collection is structured, it is information. A n example of knowledge is that 'Examine usage history of worksite' is a useful mitigation measure that can be adopted by contractors in order to mitigate the risk event ' So i l contaminated with petrochemicals encountered during excavation'. The definition provided by Davenport and Prusak (1998) has been adopted in a straightforward manner in defining knowledge management as "the exploitation and development of the knowledge assets of an organization with a view to furthering the organization's objectives ". From the perspective o f the current research, this involves developing an organization's knowledge 6 pool on risks and their management as the organization keeps on undertaking infrastructure projects, and applying (or exploiting) such knowledge on upcoming projects. Secondly, the preceding review serves to place the research leading to the development of K R I S as wel l as the functionality of K R I S in perspective among the multitude of definitions and tools related to knowledge management. In developing the K R I S methodology, a Cognitive model o f knowledge management (Kakabadse et al. 2003) has been adopted, with the focus being on the capture and storage of risk-related knowledge. The implementation of the K R I S methodology as a computer-based tool could best be characterized as belonging to the Structured Knowledge Representation Tools category identified by Davenport and Volpe l (2001), that represents knowledge and makes it available for decision making. Thus, an examination of the knowledge representation paradigms that are available is appropriate, and is presented in the following section. 6 As illustrated by the definitions introduced previously, data, information, and knowledge are articles that are tightly knit. Thus, managing knowledge necessarily involves managing the data and information that are associated with the knowledge. 35 2.4.1 Knowledge Representation Techniques The task o f knowledge representation involves organizing and coding domain knowledge into a computer system in a manner that enables effective inferencing (Meech and Kumar 1995). A representation itself can be described in terms of the distinct roles it plays (Davis et al. 1993). They are: (a) The role of a surrogate, that is a substitute for the entity itself that enables the determination of consequences by reasoning; (b) It is a set o f ontological commitments that set out the terms of how a system should be viewed, i.e. what parts of the system is the focus on and what parts are ignored or have a lesser focus. (c) It is an expression of (i) the representations' fundamental conception of intelligent reasoning; (ii) the set of inferences that the representation sanctions; and (iii) the set o f inferences that it recommends. (d) The representation is a medium for pragmatically efficient computation; (e) The medium of communication through which an understanding of the system is conveyed to machines and other humans. The techniques that are available for supporting the above roles of a knowledge representation can be classified into two broad categories. They are non-learning techniques in which knowledge has to be stored and coded manually, and machine learning techniques that have the capability to generate knowledge by sifting through large data sets and searching for patterns and associations (Desouza 2002). Rule-based approaches, semantic nets, frames, and predicate calculus are among the non-learning techniques, whereas neural networks and genetic algorithms are o f the machine-learning category. Br ie f descriptions o f these methods are given below, in some cases along with simplified examples that relate to risk management. The relative advantages and disadvantages of the methods are also cited. Semantic Networks Semantic Networks are composed o f nodes that describe facts such as physical objects or concepts, and directed links that define relevant relationships between the facts (McTear 36 and Anderson 1990; Meech and Kumar 1995), A n example o f a semantic network that relates to risk management is shown in Figure 10. The ease of visualizing and understanding the problem is a touted advantage of semantic nets. However, semantic nets can become very complex in instances where a large number o f nodes and links are required to model a system. Difficulties also exist in incorporating procedural knowledge into semantic networks. Predicate Calculus Facts are represented in predicate calculus in the form o f formulae (McTear and Anderson 1990). A formula is made up o f a predicate and a number o f arguments, while connectives such as A N D , O R , and N O T allow simple formulae to be combined into more complex ones. A n example o f predicate calculus related to risk analysis would be the formulation o f the statement, 'encountering o f contaminated soil is a risk affecting the safety performance measure', as: (ISA Contaminated soilencountered Risk) (Performancejneasureaffected Contaminated soil_encountered Safety) Predicate calculus provides a sound framework for making logical deductions. However, it is an unstructured form o f representation that can lead to difficulties in retrieving Figure 10. A Semantic Network 37 formulae related to a particular object or a concept. A further disadvantage of logic is that it does not lend itself naturally to the encoding o f procedural knowledge. Rule-based Representation A rule used in knowledge representation consists of two parts: an antecedent and a consequent, and has the syntax IF <antecedent> T H E N <consequent>. The antecedent incorporates an object and its value linked by an operator such as 'equal to' or 'greater than' in the case o f numerical values, or operators such as T S ' , ' A R E ' , or TS N O T ' in the case of linguistic values. Similar to the antecedent, the consequent contains an object and a value connected by an operator. In general, a rule can have multiple antecedents and consequents joined by the keywords ' A N D ' that signifies conjunction, ' O R ' that signifies disjunction, or a combination of both (Negnevitsky 2002). A n example o f a rule in the context o f risk management is given below. IP location of archaeological site = location of road T H E N Risk of archaeological / Paleontological remains encountered on road trace affect project IS true A N D Performance measure affected IS Duration In modeling domain knowledge using a rule-based approach, the knowledge is structured into a set o f rules o f the above form. Once encoded, the knowledge base can be utilized by processing the rules using an inferencing scheme such as backward chaining or forward chaining in order to arrive at a conclusion given an input scenario (Meech and Kumar 1995). The attractiveness of rule-based systems stems from the parallel that rules hold with natural expression o f knowledge such as rules o f thumb, the ability to separate the knowledge from its processing, and due to the uniform I F - T H E N structure o f the knowledge elements within the system. However, while the rules themselves tend to be relatively simple, their logical interactions within the large set of rules may be opaque, thus making it difficult to observe the role o f each rule within the knowledge-base. Additionally, large rule-bases can have maintenance problems, especially in ensuring the consistency o f newly added rules with the existent knowledge base. Therefore, rule-based 38 systems are generally considered to be suitable for modeling narrow, bounded domains (Meech and Kumar 1995). Frame-based Representation A frame has the advantage o f being able to represent all necessary knowledge about a particular object within a single entity. It is a data structure that represents an entity, a class of entities, or a concept, and has a set o f slots that describes the properties of the entity or the concept (Negnevitsky 2002). The slots o f a frame can include several types o f information such as: (a) slot values including default values; (b) relationship of the frame to other frames; (c) procedural information that is executed when the slot value is changed or required. Frames are generally organized as a hierarchical structure that allows inheritance. A n example o f a frame is shown in Figure 11. INSTANCE Contaminated s o i l encountered on s i t e Class: Environmental Performance measure affected: 1 Safety' Project party suited to handle risk: ,GC' Figure 11. A Frame Difficulties in expressing negation and disjunction are considered to be among the disadvantages o f a frame-based approach to knowledge representation. Case-based Reasoning Case-based reasoning is founded upon retrieving the closest past case(s) and making adjustment to it to derive a solution to a new problem at hand (Desouza 2002; Watson and Mari r 1994). A case is a problem-solution pair, in which attributes are used to describe the problem as well as the solution. Cases are considered similar i f one or more attributes defining the problem or the situation match. Case-based reasoning can be represented as a cyclical process comprising of: 39 • Retrieving the most similar cases; • Reusing the case to attempt to solve the problem at hand; • Revising the proposed solution; • Retaining the new solution as a part o f the case base. The popularity o f case-based reasoning stems from its ability to handle problems that require a situational analysis in the absence o f a clear cut causal model. However, unlike approaches such as rule-based systems that can provide an exact solution, case-based reasoning provides only an approximate solution, the accuracy o f which is dependent on the presence of similar cases with the case base. N e u r a l Networks A neural network is a system o f interconnected elements that derive motivation from the structure o f the neural paths found in the human brain, and are made up of a series of nodes which are organized into layers (Meech and Kumar 1995; Negnevitsky 2002). The nodes in one layer are interconnected to all the nodes in the adjacent layers. Three such types of layers can be found in an Artif icial Neural Net ( A N N ) structure. They are: input, output, and hidden. The input layer processes the input for the A N N . The output layer generates the output response o f a network based upon the pattern o f input received. The hidden layer lies between the input and output layer and serves as a mechanism that enhances the A N N s ability to model complex interrelationships between the inputs and the outputs. In creating a model o f a system, the A N N takes on a set o f input and output values (the learning set) and modifies the link weights between nodes i n order to minimize the output error. Therefore, neural networks generate their own rules through learning from examples which is an automated process as opposed to systems such as rule-based systems where the knowledge needs to be stored explicitly in the form of user defined rules. However, the main disadvantage o f neural networks is that they rely upon the existence o f a large set o f data, a significant handicap in risk management where significant amounts of data from past projects of a similar nature are rarely available. 40 G e n e t i c A l g o r i t h m s Genetic algorithms that fall under the broad area of evolutionary computing, simulate evolution on a computer. The result of such a simulation is a series of optimising algorithms that improves the quality o f the solution until an optimal or in some cases a feasible solution is found (Goldberg 1989; Negnevitsky 2002). In applying genetic algorithms to a problem, a variable is modeled as a chromosome usually represented by a binary string o f fixed length. Random populations of the chromosomes are generated, with the fittest chromosomes of each generation serving as most of the parents of the next generation. A n iterative process is carried out until a termination criterion is satisfied. A s is with A N N , genetic algorithms do not require explicit specification o f knowledge unlike non-learning approaches. In addition to knowledge representation methods identified above, the concepts of ontologies and intelligent agents have seen much interest in the area o f knowledge engineering. B r i e f descriptions o f these concepts are provided below. O n t o l o g i e s Every knowledge base is committed to a conceptualization of the domain it models, either explicitly or implicitly. A n ontology is an explicit specification of a conceptualization (Gruber 1995). The uses for which an ontology is developed are manifold. Three common reasons include (Uschold and Gruninger 1996): • To facilitate communication Ontologies reduce conceptual and terminological confusion by providing a unifying framework within an organization and provide an unambiguous definition of terms used in a software system. Thus, an ontology allows the development of a shared common understanding of the structure o f information within a particular domain (Noy and McGuinness 2001). • To allow interoperability between different software tools Ontologies can be used to support translation between different languages and representations to assist interoperability. 41 • Systems engineering The re-use o f models o f commonly used concepts and systems by different applications that need a representation of such a concept can be facilitated using an ontology (Noy and McGuinness 2001). Ontologies can also be useful in improving the reliability of software systems by serving as a consistency check with respect to the declarative specification. Intelligent Agents A n intelligent agent is an entity that continuously performs three functions: perception of dynamic conditions in the environment; action to affect conditions in the environment; and reasoning to interpret perceptions, solve problems, draw inferences, and determine actions (Hayes-Roth 1995). One of the most important properties of an agent is that it is able to carry out tasks independently, i.e. it is autonomous. In contrast to traditional computer applications that only respond to direct user instructions, intelligent agents can perform actions with minimal intervention from users (Desouza 2002). Another feature o f agents that is relevant to the current discussion is their intelligence or their ability to reason. Rule-based routines, neural networks, and genetic algorithms can be incorporated into agents in order to allow them to possess intelligence to interpret perceptions, draw inferences, and determine actions. Therefore, it is noted that while agents are not a means of knowledge representation unto themselves, they make use of methods o f knowledge representation in behaving intelligently. 2.5 Management of Risk-related Information and Knowledge The benefits o f organizing and managing information and knowledge relating to project risks have been recognized by many authors. Several approaches, some o f which make use o f knowledge representation techniques described in the previous section have also been suggested. The following analysis presents the state of the art in managing 42 information and knowledge 7 related to risks in c iv i l infrastructure projects. In some instances related approaches from other areas such as software engineering project management have also been cited. The discussion starts with an analysis of the most rudimentary methods and concludes with methods that have attempted to make use of advances in knowledge representation technologies. 2.5.1 Risk Categorization and Prompt Lists A logical categorization o f risks or a risk breakdown structure (Hillson 2003) can assist in risk identification, in expanding the risk awareness o f project stakeholders, and also allow common risk mitigation strategies to be developed (Al-Bahar and Crandall 1990). It can also assist in focusing attention on similar risks, and allows the re-use of models and historical information in quantifying risks that are grouped in a single category. A variety of risk categorization schemes have been suggested in the literature on project and construction management (Al-Bahar and Crandall 1990; Erikson 1979; Kangari and Boyer 1987; Leung et al. 1998; Perry and Hayes 1985b; P M I Risk Management Specific Interest Group 2002; Tah and Carr 2001; Wideman 1986). t he logic behind these schemes ranges from a division of risks as being either internal or external to the project, to a division along the stages o f the project such as design, construction, and operational risks. In some cases, e.g., Erikson (1979), the categorization schemes have been populated with risk events, allowing them to be used as a generic prompt list. Most often, the prompt lists suggested by various authors are context independent i n at least two ways -they do not relate to a specific project type, nor do they relate to the specific dimensions o f a project (physical, process, etc.). While useful in their current form as mnemonic devices, these lists can be cumbersome to use as one is faced with the task of browsing 7 In the literature, the terms knowledge and information are often used interchangeably. In describing the state of the art, the characterization used (either information or knowledge) in the source literature has been adopted. In describing aspects of the KRIS methodology in the following chapters, an attempt has been made to distinguish between the two articles, wherever such a distinction is critical in imparting the desired message to the reader. 43 through the multitude of risk items and determining their relevance to the various projects that an organization undertakes which could be quite diverse such as a waste water treatment plant in one instance and a bridge in another. A step up from these generic lists are prompt lists in paper form that catalogue risks for particular types of projects such as coastal projects (Cruickshank and S imm 1998) and construction in rivers and estuaries (Morris and Simm 2000). In some instances these risks are mapped onto specific construction operations. 2.5.2 Risk Registers A further evolution in the process o f managing risk-related information and knowledge involves the compilation of a risk register for a specific construction project. A risk register or a risk log is a mechanism to record the risks that are identified for a particular project and to track them through the project's lifecycle. Its use is widely advocated in industry (Crossland et al. 1998). Ward (1999) and the Office o f Government Commerce (2005) envision the risk register as a tool that helps the project team review project risks on a regular basis throughout the project. Information about the timing of risks and responses, resources required by alternative responses, information about interdependencies, as wel l as information on the nature of impacts and risk ownership have been suggested as important register contents by Ward. The Department o f Premier and Cabinet - Tasmania (2004) stresses the usefulness o f the register as a mechanism for seeking and acting on feedback to encourage the involvement of key stakeholders. The register contents suggested by the Tasmanian government for industry use includes the party responsible for managing the risk, a grading of the risk according to a risk impact matrix, and an outline of proposed mitigation actions. However, Ward (1999) criticizes the use o f results from probability impact grids for prioritizing risks in the register, suggesting instead that more attention should be paid to the linkages between the risks and the responses that could be adopted. Wil l iams (1994) identifies two main roles of a risk register: (i) The risk register is a corpus of knowledge about the current project, and (ii) It acts as a tool that initiates risk analysis and response planning. The register structure suggested by Will iams categorizes 44 its content into four main categories. These are risk event information, impact information, details on risk reduction actions and contingency measures, and contractual details. To date, several risk registers have been implemented as computer tools. Among them is Risk Radar (Integrated Computer Engineering Inc. 2002) which is a Microsoft Access database that allows the user to track and manage project risks. It allows the input o f identified risks, impacts and probabilities in qualitative terms, and mitigation and contingency steps. The mitigation measures can be archived for re-use. Risk exposure durations are also defined by the user, which in turn allows the system to appraise the user on upcoming risks. A change in the risk impact, which is modeled through a risk impact matrix, is also logged over time. The screening procedure for risks in Risk Radar is limited to filtering risks by possible timeline o f exposure, and the level o f risk. SiteRisk (Andersen and Madsen 2001) programmed in Microsoft Access is another computer tool that employs a risk register. It contains details on construction activities and risk issues in two different tables. The parameters are linked through relations in the database. This permits the user to access information across projects, and activities. SiteRisk has also been cited under knowledge-based systems in the following section as it allows text that describes past experience to be linked to entries in the databases. The Risk Register Database System developed for the automotive industry (Patterson and Neailey 2002) contains information such as risk owner, assessments o f the probability and impact of the risk, and phase / time by which the risk should be evaluated. The system allows reports to be generated which act as status updates on the risks of the project. The Risk Register Database System has also been developed using Microsoft Access. H a l l et al. (2001) describe a spreadsheet-based software tool termed R i skCom that allows the user to record information during the different stages o f risk management. Pre-programmed help functions that provide instructions and information on different stages o f the risk management process guide the user through the different stages. Tah and Carr (2001) describe P R I M E , a software tool that makes use of a hierarchical risk breakdown structure that defines risks using five terms: type, scope, centre, risk, and risk factor. Catalogues o f risks, remedial actions that are available for alleviating risks, and relationships between the risks and remedial actions are available 45 within P R I M E . Information modeled includes scope of risk and its likelihood and consequence in qualitative terms. P R I M E is cited again under knowledge-based systems in the following section as it makes use o f fuzzy logic and rules in risk quantification. 2.5.3 Knowledge-based Systems for Risk Management The characteristics o f several systems that are reflective o f currently available knowledge-based approaches are summarized under five key themes in Table 3. A n explanation of the headings of the table is as follows: (1) Implementation: This category details whether the system is a working prototype, or a full working model. It also provides an assessment of the generality o f the domain to which the system can be applied, i.e. whether the application of the system is restricted to certain types o f projects, or whether it is broadly applicable. (2) Input / Output: This category describes the nature o f the information required by the system from the user, and the character of the output produced by the system. (3) Mode l o f Product / Processes / Environment / Organization: This is a description of how the projects' physical characteristics and processes, the organizations involved, and the characteristics o f the environment in which it is located are represented in the knowledge-based system. For example, in some systems project components are represented as arguments o f production rules, while some other systems provide templates that set out project components. The support provided by the systems for modeling defining attributes o f the project at hand is also described. (4) Nature o f knowledge-base: This category provides a description o f the form and characteristics o f the knowledge stored by the system (e.g., rules, cases, templates). The use of risk registers and checklists to accumulate and categorize information about risk events is also described. Furthermore, the application of approaches such as fuzzy logic to support qualitative input / output is highlighted. (5) Risk management functions supported: The support the system provides for individual risk management functions (e.g., risk identification) using knowledge-based strategies such as production rules or case-based reasoning is described in this category. 46 Specific approaches taken towards risk quantification (e.g. use of Bayesian probabilities, fuzzy logic) are identified, where applicable. A commentary on the relative strengths and shortcomings of the approaches summarized in Table 3 is presented in the next chapter within section 3.2. It is also noted that the approaches described in Table 3 relate to c iv i l infrastructure projects8. Research in other subject areas that merit discussion include a fuzzy case-based reasoning system developed by Cox (1999) that applies to software development projects, and the Project Risk Management methodology (Alquier and Tignol 2001) intended for supporting the bidding process o f industrial product development projects. Risk Consultant (Eon Solutions Ltd 2005) is a commercially available system for managing the security risks associated with IT systems in business enterprises, and is rule-based. 8 The Technical Risk Identification and Mitigation System (TRIMS) developed by the (Best Manufacturing Practices Center of Excellence 2001) has been included within Table 3 as it allows process templates to be developed for any type of project, even though it has been originally developed for industrial projects such as missile fabrication. 47 Table 3. Comparative analysis o f knowledge-based systems for risk management System Implementation Input / Output Model of product/ process/ organization/ environment Nature of knowledge base Functions supported Project Risk knowledge Management Environment ( P R I M E ) (Tab. and Carr 2001) Research prototype. Input: Likel ihood and severity o f risk factors in linguistic form. Output: Risk effect on work tasks in linguistic form. (e.g. possible change in earthwork cost is "medium"). Product, organizational, and environmental models are absent. Output refers to impact on process components (work tasks). Rule-based. Utilizes fuzzy logic in risk quantification. Fuzzy associative maps set out the risk magnitude given the likelihood and the severity of the risk factors that are subjectively assigned by user. The total effect o f many factors is computed if necessary. Risk factors that have been considered include Weather, Plant availability, Site investigation, and Plant suitability. Risk quantification. Cost, schedule, safety, & quality risks are considered. Technical Risk Identification and Mitigation System ( T R I M S ) (Best Manufacturing Practices Center o f Excellence 2001) F u l l working system being used mainly by U S defense contractors. The current knowledge-base is applicable to software development projects, and typical military acquisition projects such as missile production. Input: Min imal . Restricted to project milestones, and answers to queries on whether specific actions have been carried out. Output: Risk level o f project elements in terms o f "High", "Medium" and "Low". Specific actions (or their non-implementation) that contribute to the risk level can be identified. Process-based. Fairly detailed, generic models o f standard project types are part o f the system. Knowledge about projects are captured in templates that set out typical activities o f specific project types. Actions that act as risk mitigators are attached to each element of the template. Reasoning about the risk level is based on the level o f compliance to each activity. Risk identification. Risk quantification is also carried out through assignment o f weights that signify the importance o f risk-related actions. The risk level is obtained by summing up the weights o f non-compliant activities and comparing the value with pre-defined thresholds. Table 3. continued. System Implementation Input / Output Model of product/ process/ organization/ environment Nature of knowledge base Functions supported SiteRisk (Andersen and Madsen2001) Prototype system implemented in the form of a MS Access database. Input: Queries to the database. Output: Risk events Database holds a listing of construction activities. Static knowledge is held in a relational database. Risk related data stored in the database includes Risk area, Risk, and Risk Event, which are linked to construction activities through relations. Text that describes past experience is linked to entries in the databases. Risk identification. Risk Assessment System for Construction Schedules (Mulholland and Christian 1999) Prototype system developed using HyperCard. Input: Minimal. Output: Pages of information providing data and information on schedule risk factors. Product, process, organizational, and environmental models are absent. A Hypertext system is used to store information on previously experienced risks. The information can be in the form of text, graphics, or pictures. Risk factors relating to four dimensions: engineering design; procurement; construction; and project management, are contained within the body of information. Examples of risk factors include Productivity, Design errors, and Design criteria. The importance of the risk factors are characterized as "high", and "low", broadly for all projects. The confidence of the risk factors occurring is also expressed using similar linguistic expressions. The system allows the user to easily navigate through the information by providing mini-maps of documents visited. Risk identification. Table 3. continued. System Implementation Input / Output Model of product/ process/ organization/ environment Nature of knowledge base Functions supported Knowledge-based Risk Identification System (Leung etal . 1998) Prototype developed for extra high voltage transmission line construction projects. Input: Selection o f project activities & risk factors from list. Output: Risks & risk-related work packages N o product or organizational models. Work Breakdown Structure ( W B S ) is used to model the processes. The activities o f the W B S serve as arguments o f the rules. Attributes o f activities are not modeled. Environmental conditions are modeled implicitly as risk factors. Rule-based. Forward chaining. Rules take the form "IF Public consultation A N D Permits and government approvals T H E N Design changes". Risk identification. Human-computer cooperative system for knowledge-based risk management in engineering (Niwa 1989) Working system. Has been applied to construction projects. Input: Project components and activities. Risk factors applicable to the project need to be selected by the user. Output: Probable risks that wil l be encountered on the project are identified. Backward chaining to verify the hypothesis that a risk wi l l occur is also possible. Models of project components and activities that take the form of a list are utilized. N o environment models. Some environmental and organizational components are incorporated through the risk factors. Attributes that describe the context o f the project being analyzed are not used in the models / factors. Rule-based with the ability to chain both backward and forward. Related risks are also identified by associating them through keywords. Risk identification. Table 3. continued. System Implementation Input / Output Model of product/ process/ organization/ environment Nature of knowledge base Functions supported Expert Risk (Kangari and Boyer 1987) Micro computer-based prototype implemented using INSIGHT 2+ expert system shell. Integrated with databases containing cost data, weather data, productivity data etc. Linguistic I/O through the use of fuzzy sets. Input: Selection of risk factors from list, definition of risk policy to be adopted, magnitude of risk factors in linguistic terms. Output: Expected cost of activities and their variance, and risk responses. No product, organizational, or environmental models. Activities serve as arguments in rules. Attributes of the activities are not considered. Consists of a set of production rules. Use of fuzzy logic is made in combining values provided by user for different risk factors, in order to calculate overall risk. Rule-base is used to reason about suitable responses for risk factors. Examples of the factors considered are "Uncertainty of inflation", "Public disorder", and "Labor disputes risk". Risk quantification, by providing a linguistic measure for overall risk. Risk response development, by suggesting management actions. Intelligent Risk Identification System (Ashley and Perng 1987) Prototype. Input: Selection of a specific problem category, project type, contract type Output: Problems associated with specific problem areas, and the influence diagram that sets out the "influenced by" and "influence on" problems / variables. Project type and other characteristics provide the abstraction of the product. Attributes such as contract type provide a definition of the environment. Process models are absent. Output refers to problems associated with processes. Rule-based representation along with the query evaluation capability of a database management system holding information on problem statements. Risk identification. Quantification of the probability of occurrence of problems through the use of influence diagrams and Bayesian probability. 3 Beyond the State of the Art - Challenges and the Solution Paradigm 3.1 Introduction Described in the previous chapter were a variety of methods such as prompt lists and risk registers that are currently used in managing risk-related information. The pioneering work by the architects o f such approaches has resulted in advances being made in defining a significant portion of the information that should be contained within a risk register, and in implementing registers as computer databases. In some instances, knowledge-based methodologies, the majority o f which rely on production rules, have also been proposed. In looking to build upon these efforts, one has to be cognizant of the practical realities and challenges an organization has to contend with while applying information and knowledge in managing the risks o f a large infrastructure project and in attempting to re-use such content on future projects that it may undertake. 3.1.1 Heterogeneity and Numerousity of Risks and Risk Drivers The scale and complexity o f infrastructure projects, the involvement of a multitude o f stakeholders with diverse viewpoints, and ever increasing requirements to manage environmental impacts can result in the sets of risks encountered on such projects being rather sizeable. The risks themselves are heterogeneous ranging from undulations in long-term interest rates that result in difficulties in maintaining an adequate D S C R to physical events such as a landslide that sweeps away part o f a highway project resulting in human casualties as wel l as monetary implications. In addition to differences in their consequences, other aspects such as the mitigatory tactics that are applicable can also be very different among the risks, as w i l l be the stakeholders who w i l l bear responsibility for each risk. Thus, in attempting to manage the information regarding project risks, the need arises to model not only a sizeable and diverse set o f risks, but also their characteristics such as applicable mitigatory measures and so forth. 52 Also of interest in managing the risks are their causes. Fundamentally, uncertainty can be categorized into two major groups, which are aleatory and epistemic (Abrahamsson 2002). Aleatory uncertainty, also identified as stochastic uncertainty, represents the randomness of nature (including randomness in human behaviour), while epistemic uncertainty represents a lack of knowledge about a phenomenon. A n example o f aleatory uncertainty in an infrastructure project is the randomness of weather patterns, while an example o f epistemic uncertainty is the unpredictability o f performance o f a novel structure, such as a submerged floating tunnel, peers of which do not exist anywhere in the world (British Columbia Ministry o f Transportation 2003b). More important than the distinction between the types of uncertainty is the fact that such uncertainties which afflict constituents o f a project or its environment are the driving force behind the risks o f an infrastructure project. For example, uncertainty in weather patterns can result in risks such as a reduction in the construction time windows. Unpredictability in the performance o f a novel structure can increase the exposure to the risk o f the structure not performing as required during operation. It is noted that in some cases a risk may be driven by a combination of such sources. Thus, in order to successfully manage the risks o f a project one needs to have an understanding o f the components 9 that make up the project and its environment 1 0, i.e., the factors driving the risks o f that particular project. A large infrastructure project consists of physical components that make up the temporary and permanent structures of the project, process components that are required to procure and operate it, as wel l as the project participants who manage and execute the processes. These project component ensembles are located within an environment that consists of physical components (both man-made and natural), as wel l as economic / financial, social, political, and regulatory components as shown in Figure 12. 9 The term 'Component' is used to refer to a constituent part, i.e. an element (Project Management Institute 2000) of the project or its environment. 1 0 Herein referred to as 'project context components'. 53 Figure 12. Constituents of the Project Context The combinations o f components encountered on one project an organization undertakes w i l l be different to the combination encountered on another, resulting in different risk profdes between projects. A s previously mentioned, in managing risks and primarily in identifying the set o f risks that are applicable to a project, one needs to be cognizant of the particular combination o f components that make up the scenario being considered, i.e., it is desirable to have a model o f the project context. However, the number and kind o f components that need to be modeled could be non-trivial, especially i f a more detailed model that can provide increased insights into the risks driven by individual components is used. Similar to the risks that they drive, the components are heterogeneous in nature ranging from endangered tailed frogs that could be part of the physical environment to an organizational participant such as a contractor inexperienced in P3 projects. In a nutshell, the set o f information to be managed is significantly large and diverse. Compounding the modeling exercise is the lack of consistent terminology in defining components o f some 54 segments o f the project context as well as in identifying the concepts related to risks and in characterising individual risks and their properties. 3.1.2 Diversity o f Projects Organizations such as government agencies and ministries, large engineering firms, and investment bankers are among the primary players in infrastructure projects undertaken as P3s. The projects undertaken by such organizations tend to be rather disparate. For example, the list o f projects that Partnerships British Columbia (PBC) , a government owned entity is involved with includes a hospital project, a mine waste water treatment plant, a sports centre, and several transportation projects (Partnerships Brit ish Columbia 2005a). SNC-Lava l in , a large engineering firm lists among its experience a man made river, hospital projects, and airports in addition to its current involvement in transportation projects i n B C including the Richmond-Airport-Vancouver transit line (SNC-Laval in 2005). The Macquarie group provides specialist investment banking services and lists toll roads, rail transportation projects, and airports among the many projects it is involved with (Macquarie Bank Ltd . 2005). Even in instances where an organization is involved with several projects o f a similar type (e.g., bridge projects), their designs and the environments in which they are located can be quite different. This is the case for P B C with regards to the Okanagan Lake Bridge (Province o f Brit ish Columbia 2005b), a floating bridge that has a very small number of peers worldwide, serves as the only major crossing across the Okanagan lake, and is located in an environment that is heavily used for recreational purposes, as opposed to the Golden Ears bridge (Greater Vancouver Transportation Authority 2005) that has several parallel crossings and is located in an urban / industrialized area. Therefore, the set o f project components and the profile of risks are unlikely to be replicated in the exact same manner between the projects an organization would undertake, even in instances when the projects are o f a similar type. This precludes straightforward utilization of information and knowledge gained on past projects. Thus, an organization is faced with the task o f somehow moulding the information and knowledge gained on previous projects in a 55 manner that would assist it in identifying, quantifying, and responding to risks on future projects. 3.1.3 Omnipresent Change The scope and requirements desired of infrastructure projects and the perspectives of different stakeholders towards such projects tend to be notoriously fickle. A cabinet reshuffle that brings about a minister less wi l l ing to be a political champion o f an infrastructure venture may result in a project being shelved or downsized. Such scenarios may also arise due to unexpected, unrelated, or distant episodes, such as the events of September 11, 2001 that had the potential to affect planning and development o f airport infrastructure. Thus, change is to be expected in infrastructure projects, followed by a changed spectrum of risks. The extended period during inception and contract signing, an oft cited disadvantage o f the P3 approach, can mean that the set of risks that were identified by the government or a private sector bidder at say the R E O I stage could l ikely change as the project moves onto later stages such as the R F P stage, due to changes in project configuration or changes in the regulatory, political, or economic environments. While a P3 approach is said to be somewhat immune to client requested changes subsequent to contract signing due to the adoption of performance-based specifications, instances where changes are made can still be found. A n example is the Richmond-Airport-Vancouver transit line in British Columbia, that underwent changes such as deferring the construction o f a previously planned station due to a review of the operation plan o f the Vancouver International Airport, a primary stakeholder of the project (Boei 2005). Thus, in modeling the risks o f a project, flexibility needs to be provided for the risk profile to be changed in accordance with changes in the project context, or more preferably to assist users in identifying the transformations to the risk profile that arises as a result of such changes. 3.2 The State of the A r t and Beyond The issues and associated challenges identified above severely test the capabilities o f existing approaches for managing risk-related information and knowledge. Risk registers, 56 either in paper-based form or in the form of spread sheets or databases are poorly suited to accommodate changes in the risk profde that accompany changes in the project context. In their current form risk registers do not incorporate an explicit representation o f the project, and given that the circumstances of a project change, for example due to a change in regulations or change in design, the users o f a risk register have to manually identify risks that were related to the original state of affairs, eliminate the risks that are no longer applicable, and then identify new risks that relate to the changed circumstances. Additionally, the large number o f risks and the significant number o f information elements associated with each risk tend to make the use of a paper-based or spread-sheet based form o f a risk register extremely difficult to navigate. Ease of navigation is a feature decidedly desirable during the tasks o f risk identification and risk allocation that typically require input from a group of individuals with various backgrounds such as engineering and financing. Registers based on the use o f databases such as M S Access can overcome this latter disadvantage with the use o f forms that present information on a selective basis and also have the capability to support queries. However, the queries that can be generated on databases or keyword searches that can be performed on spreadsheet representations o f risk registers are hampered by two factors, the first being a lack o f consistent terminology that leaves the user guessing as to what to search for, and the second being the lack of an association with a model o f the project thus precluding searches such as the risks associated with a particular process and so forth. The lack o f explicit representations of the project context that are integrated with risk information also hampers attempts to re-use the contents o f risk registers on future projects. Risk registers that have been implemented as computer databases for the construction phase as wel l as for other project phases (Patterson and Neailey 2002), are primarily focused on supporting the current project being analysed. Whi le arguably the information in such databases can be re-used on future projects, data and information from past projects have limited usefulness in the absence o f a rich representation of their context (Rezgui 2001). Thus, the use o f past registers that do not incorporate information as to the context they relate to, is limited to the role o f a prompt list, placing the burden on the user o f reasoning and selecting risk issues that are relevant to the project at hand. 57 In considering knowledge-based approaches, rule-based systems while attractive for application to a restricted domain (for example to identify construction risks o f high-rise condominium projects in downtown Vancouver), would tend to become very complex i f used to cater to an organization that undertakes different types o f projects in different environments, each with a large number of risks and project, process, organizational, and environmental components. Thus, any attempt to develop a rule-based system would l ikely result in a very large set o f rules. The reasoning logic of such a large rule-base would be fairly opaque and have a black box appearance to non-expert users, and most l ikely would also require an expert to maintain. State of the art knowledge-based systems (see Table 3) have thus limited themselves to supporting a subset of project types such as high voltage transmission line projects (Leung et al. 1998). Such approaches have also limited themselves to supporting only a subset of risk management functions such as identification (Leung et al. 1998) or quantification and response development (Kangari and Boyer 1987). The treatment o f the project context by currently available knowledge-based approaches, rule-based or otherwise, is fairly sparse. The few approaches that model information about the components o f the physical dimension o f a project and their attributes, treat them as static arguments of production rules (Kangari and Boyer 1987; Leung et al. 1998). A handful of approaches require information about the processes o f the project (Andersen 2001; Best Manufacturing Practices Center of Excellence 2001; N i w a 1989). The approaches proposed by Leung et al. (1998) and N i w a (1989) treat aspects of the environment and the organizational structure by modeling some environmental and organizational components as risk factors within the rule-based approaches they propose. However, it is noted that the components that have been modeled within these systems are a very small subset of the components that typically make up the context o f a project. Additionally, none o f the approaches treat all four dimensions (physical, process, organizational, environmental) instead focusing on one particular aspect, an example being T R I M S (Best Manufacturing Practices Center o f Excellence 2001) which takes a process-centric approach. A further disadvantage o f current approaches is that the knowledge is mostly in static, hard-coded form, lessening the ability of practitioners to add lessons learnt. The 58 large number of project context components as wel l as the risks likely to be encountered by an organization as it undertakes different projects makes it l ikely that a knowledge repository o f significant breadth can only be developed over an extended period o f time. Amending or augmenting the knowledge-bases of most systems currently available would require altering the rule-bases which are their primary repositories of knowledge. The necessity to ensure consistency in terminology among existing rules and newly added / edited rules could make this procedure potentially difficult, especially in cases where a large number o f rules are involved. A n exception is T R I M S (Best Manufacturing Practices Center o f Excellence 2001) that allows process templates and associated risk mitigation measures to be developed over time for specific project types. Thus, while current approaches for managing risk-related information and knowledge are to be commended for their pioneering effort, considerable work remains to be done in developing an approach that meets the challenges posed by the characteristics of the risk management domain. The specific research objectives aimed at successfully taking this next step were identified in section 1.2. They are: • Identifying the core set o f information and knowledge groups used in managing economic risks as wel l as the concepts that are applied in the process; • Developing a set o f constructs that can be used within a computerized environment to model the information and knowledge related to risks as well as the aspects of the project context that are o f relevance to risk management; and, • Formalizing a methodology that allows representations of the risk-related information and knowledge to be generalized and stored in a project neutral format, and facilitates the extraction and use of the project-neutral representations in developing a model of the risk profile on future projects. A s discussed earlier, K R I S is aimed primarily towards supporting the planning, procurement, and the contracting phases o f a project, as these are the phases during which strategic decisions are made by both the public and private sector. Risk management provides critical input to these decisions with the contributions coming from all steps o f the risk management process, i.e., risk identification, risk quantification, and risk 59 response. Putting it briefly, identification provides the risk profile of the overall project as well as the risks relating to particular aspects of the project allowing decisions to be made as to the project viability and as to whether changes are required in certain aspects of the project that are risk prone. Quantification provides critical input to the P S C and the bids of the private sector, while the task o f risk response allocates risks among the project stakeholders and generates other strategies that are used in moulding the risk profiles of such stakeholders. It is noted that the information used during the different tasks o f risk management flows from one task to another, i.e., the information requirements are not independent o f each other. Selection o f a risk quantification method requires the characteristics of the identified risks as input, while risk responses may depend upon the assessment of the significance o f the risks determined during risk quantification. The responses selected can themselves trigger additional risks that need to be identified in turn. The pools of information relating to these different tasks can thus be considered as being inexorably linked. Therefore, in modeling risk related information and knowledge, an approach that supports all steps of risk management and facilitates information flow from one risk management function to another is therefore desirable. Furthermore, the ability to model information relevant to all the tasks ensures the consistency and accuracy of the information as it flows from one risk management function to another. The first research objective relates to identifying the core set of information that is used in all steps of risk management during the front end o f a project. Keeping in line with the focus of supporting strategic decisions made during such stages of a project, the domain of K R I S does not extend to modeling information and knowledge related to the ongoing management o f risk during project implementation, such as details o f symptoms that signal the possible occurrence of a risk and so forth. Modeling such content is a natural extension to K R I S and has been discussed further in the section on future work in Chapter 6. The second and third research objectives deal with facilitating the use o f content related to the concepts identified as part of the first objective on a current project, and their re-use on future projects. It is noted that K R I S is intended to be a facilitative tool supporting the use o f information and knowledge that is generated during risk management as opposed to a computer system that aims to provide all or some o f the 60 answers that professionals involved in the risk management exercise o f a project might require, i.e., it is not an expert system. While expert systems can be useful in supporting a set o f functions within a narrow domain as discussed previously, the complexities of infrastructure projects as well as the diversity of projects that an organization is likely to undertake pose significant challenges to the development and maintenance of an expert system. Therefore, in considering currently available approaches K R I S is more related to risk registers in their most extended form as opposed to narrowly focused "answer-based" approaches such as rule-based expert systems. A s discussed previously, issues such as a lack o f representation of the context to which information and knowledge applies, as well as a lack o f standard terminology in describing concepts and content make risk registers in their current form of limited use on future projects, while also constraining their ability to allow searching and visualizing of the content and changes to be made to the risk profile in response to changes in the project context. The goal o f the second and third objective is to overcome such shortcomings. Specifically, K R I S aims to allow users to develop a model of the project context and its risk profile using the relationships between the two to ensure that the profile stays in focus with changes in the project context. The definition and use of standard terminology is also facilitated and leveraged along with the associations between context components and risks in facilitating queries and analysis, and in facilitating information and knowledge re-use. 3.2.1 Research Questions A t this point of the discussion it is worthwhile to dwell upon the meaning of meeting the research objectives, i.e., what is the contribution or more specifically what issues are addressed? It is noted that the path to meeting the research objectives lies not in the straightforward selection o f a modeling approach, but in answering a series of relevant questions that relate to the challenges of the risk management domain. In the opinion o f the author, the research challenges or questions which need to be addressed are as follows: 61 1. A fundamental question that needs to be addressed is the identification of the most appropriate role(s) for the machine and the system users in developing a computer-based methodology. Does one attempt to opt for a higher degree of automation at the expense o f flexibility in terms o f the ability to model a diverse range of project types and the ability o f users to add/edit the contents or vice versa? Hence, what computing technologies and approaches are most applicable? 2. H o w can the set of risks that pertain to an infrastructure project be represented? H o w can issues such as the absence of standards in risk categorisation and the need to provide ease o f navigation among a large set of risks be factored into the model? What are the properties of individual risks (e.g., the project phase to which the risk pertains, the project stakeholder responsible for the risk) which are important in carrying out the various tasks o f risk management (i.e., identifying, quantifying, and developing responses), and how should such properties be modeled? 3. H o w can the relationship between the project context and the risks o f a project be represented? Furthermore, how can the project context be modeled in support of representing that relationship? 4. H o w can the representations o f project risks, their properties, and the relationship with the project context be exploited in order to gain additional insights that can assist in the decision making process? What are the functions (e.g., querying, reporting) and formats which are o f use? 5. What is the information and knowledge content that can be re-used between projects? H o w can such content be archived in a project neutral format? How can issues such as the lack of standards in describing risks / aspects o f the project and the need to allow ongoing build-up of content be overcome? H o w can the content from past projects be extracted from the archives and what sort o f assistance can be given to the user in deciding the appropriate content to re-use? 62 The research being described extends the state of the art in managing 1 1 risk-related information and knowledge by presenting answers to these challenges and questions, which are incompletely treated by current approaches. The degree to which current approaches answer the research questions are discussed in sections o f the thesis that presents the approach taken by K R I S in answering individual questions, thus setting out the point of departure as well as the incremental contribution. The objective o f tools such as risk registers and knowledge-based systems in the risk management domain is to ensure that the user gets assistance in identifying as completely as possible the risks of the project, in deciding on how best to quantify the risks, in quantifying the risks either in numerical or qualitative terms, and in deciding on how to optimally mitigate the risks through strategies including the use of risk allocation. The objective o f an organization in executing risk management is to minimize its exposure to downside risks and maximize its exposure to upside risks, or in some cases to minimize risk altogether. H o w successfully an organization achieves its goal depends upon the capabilities o f the tools it employs among other factors 1 2. Failure to identify a significant risk(s) can wreak havoc with project success, whilst adopting a less than optimal risk mitigation measure such as the transfer o f a risk to an inexperienced stakeholder can result in the risk returning in a haunting fashion. Whilst it is not always possible to measure the contribution o f a tool in terms o f the dollar amount it saves or the number o f worker injuries that it helps to prevent, it can be asserted that providing a tool that allows an organization to make use of past experience, allows it to derive insights from the profde o f identified risks through the use o f functionality such as querying and reporting, and allows such a profile to be updated in sync with changes in the project context can go 1 1 As defined in the previous chapter managing knowledge is "the exploitation and development of the knowledge assets of an organization with a view to furthering the organization's objectives". This involves developing an organization's knowledge pool on risk management as the organization keeps on undertaking infrastructure projects, and applying (or exploiting) such knowledge on upcoming projects. Note: The term 'knowledge' is used to collectively refer to data, information, and knowledge. 1 2 Other factors that affect the success of the risk management process include managerial commitment and availability of resources. 63 a long way in assisting an organization to successfully manage risks. The contribution o f K R I S in this regard comes in two forms. First it answers the individual research questions identified above which relate to the practical and intellectual challenges of the risk management domain, and which have been treated rather incompletely and impracticably by the state of the art. B y doing so it resolves individual issues such as difficulties in deriving insights from the set of risk information within tools such as risk registers. Secondly and more importantly, it answers all o f the questions in unison, a feature that makes it decisively stand out in comparison to existing approaches. B y answering the questions in unison, the user is provided with the power or the capability to not only simply manage and analyse a static set of risks, but to make dynamic changes in response to changes in the project, as well as to make use o f past information and knowledge in carrying out management functions, and thus guide an organization towards its ultimate objectives in risk management. 3.3 Risk Workshops Prior to getting onto the details o f the K R I S approach, the scenario of a risk workshop is presented. The commentary is on what takes place at a risk workshop rather than a description o f the application o f a particular approach that assists in the task, with the aim being to relate the circumstances under which K R I S or any other approach would be used to assist in managing the risks of an individual project. In presenting the scenario, use is made o f examples drawn from the O L B project and the user is referred back to Chapter 1 wherein a broad overview o f the project is presented. To summarize, the O L B project involves replacing an existing three-lane floating bridge with a new five-lane bridge. Issues such as the need to maintain traffic across the lake crossing and the scarcity of floating bridges and associated design guidelines in the world are among causes o f concern. The government wishes to explore the possibility o f using a P3 approach to achieve value for money in procuring the facility. The perspective of a government agency entrusted with the task of procuring the project is taken in describing a risk workshop taking place at an early stage (prior to the R F P ) of the project. 64 Risk workshops (Morris and Simm 2000) are a gathering of a set of personnel who, in a series o f sessions, carry out various tasks o f the risk management process. Among the primary tasks addressed are risk identification which is the most crucial step of risk management, assignment o f values to the risks, and the development of mitigation measures including making preliminary decisions as to the ownership of risks. For a project such as the O L B , the group o f participants could include the project director, project managers, bridge designers, transportation specialists, highway designers, personnel with expertise on First Nations issues, legal personnel, experts on fisheries and wildlife, and personnel with financing backgrounds. Attention is drawn to the diversity o f the backgrounds of the personnel involved who in line with their expertise would tend to have a particular focus on the project, be it the business deal, the technological intricacies, or the environmental implications, and in some cases might not fully appreciate the significance o f the risks that lie outside their domain of expertise. A workshop facilitator conveys the objectives of the workshop to the participants, leads the participants through processes such as identifying and quantifying risks, and moderates discussions. In some instances, the facilitator may also act as a recorder who documents the risks identified and other relevant information, whereas in other instances a separate individual may be dedicated to the task (Cruickshank and S imm 1998). The workshop begins with introductions, a discussion o f the aims of the workshop, and a discussion o f the project objectives. The project objectives discussed include general objectives, which in the case of the O L B are to meet traffic demand until the years 2018-2023 and longer term demand i f possible, ensure that the existing bridge continues to serve traffic demand while the new crossing is constructed, and provide improved safety to the public (vehicular, pedestrian, and cyclists) (Province of British Columbia 2004). More specific details are then addressed such as the anticipated time frames o f delivery, and the private sector responsibilities i f a P3 approach is adopted. In the case o f the O L B , the private sector responsibilities are to deliver the following services: (a) Operation and maintenance o f the existing bridge pending the completion of the new crossing, and the eventual decommissioning of the existing bridge; 65 (b) Design, build, commissioning and testing of the new crossing, and operation and maintenance o f the new crossing; (c) Operation and maintenance of the Westside works; and (d) Financing of all such activities. The group then proceeds to identify and discuss the risks o f the project. It is noted that government cannot simply focus on identifying the risks that it plans to own. Firstly, it needs to know what it is transferring to the private sector, and secondly it needs a complete as possible set of risks to meaningfully make use o f a P S C in decision making as w i l l be explained below. In carrying out risk identification the workshop participants study various details of the project such as the projected traffic forecasts, details of the environment, reports on the geotechnical conditions of the site, and any designs the government has developed in attempting to use a traditional delivery approach. Such content could be very sparse or could be in the form o f lengthy reports or a large set o f design drawings. The content could also be very accurate and up to date or tend closely towards being obsolete. For example, in the case of the O L B project, field research details of two archaeological sites within the project footprint are available, while details o f two other sites are not available due to difficulties in getting access to the sites, thus requiring that the participants make use o f information with varying degrees of detail. In addition to gathering such types o f information, the participants also need to make several assumptions. For example, what would be the design solution and the construction process that the private sector would most likely adopt and what sort o f strengths and weaknesses can be expected o f the bidding teams. In analysing available information and making assumptions the participants might refer to external sources o f information such as websites, research reports, and trade journals. For example, websites and other literature giving details o f a floating bridge constructed elsewhere in the world such as the Hood Canal Bridge in Port Angeles, W A (Washington State Department of Transportation 2005) could be o f interest to workshop participants. The information elements and assumptions relating to the various project aspects can be relevant to the expertise and interest o f several workshop participants. For example, the anticipated time frames associated with pontoon construction would be of interest to 66 project managers aiming to identify risks that could warp such time frames, as wel l as to a fisheries expert concerned with issues related to the filling and de-watering of the dry dock used for pontoon construction. Therefore, the participants attempt to gain a clear and shared understanding of the project. They also frequently navigate within the project information and external sources o f information in clarifying details as they attempt to accurately identify and address risks. A s the risk identification task progresses, the list o f risks generated are entered into a risk register. In addition to the listing o f risks, properties o f the risks such as the probabilities associated with their occurrence are also recorded. Preliminary decisions as to whether the risk is to be transferred or retained would also be made. Consensus may or may not be achieved on the validity of a particular risk and its properties such as probabilities, as wel l as on whether it is to be retained or transferred. Participants might in some cases decide to move on to another risk i f consensus is not forthcoming, electing to address it at a later stage. In other instances clarification may be required from external sources, resulting in the need for a risk to be left partly addressed until a future workshop session. Furthermore, participants in unison or individually may also have second thoughts regarding a risk subsequent to addressing a related issue and wish to revisit some o f the risks previously identified. Instances may also arise where participants feel that changes in the assumptions made initially are desirable based on the risks generated. For example, i f one of the assumptions was that the private sector would employ a temporary bridge at some stage o f the project, and as the risk workshop progresses it becomes obvious that such a solution is highly risk-prone, such an assumption could be changed as it is unlikely that the private sector would adopt such a solution. Thus, the process is quite iterative requiring navigating among the listing of risks that becomes progressively larger. On completion of the risk workshop, its output is fed into the P S C and associated cash flow models o f the project, as wel l as to the task o f risk allocation. A s described in Chapter 2, a P S C is an important element o f the decision making process o f the government with risk management providing critical input to the P S C . The evaluation of the viability o f the P3 process as wel l as the private sector bids includes a comparison o f the P S C against the N P C of the government's cash flow profile under a P3 approach. It is 67 noted that in developing the government's cash flow model for the P3, the government in most cases utilizes a shadow bid approach, i.e., it prepares a cash flow model taking the perspective o f the private sector concessionaire and uses it to feed the government's cash flow model. Thus, the need for the government to consider the risks that the private sector would l ikely be responsible for, as wel l as to try to gain an insight as to the likely mitigation measures that the private sector might adopt. The ultimate aim in most cases is to assign a number for these risks, as wel l as the risks that the government would own and to incorporate these numbers into the cash flow model of the project. The risk numbers could appear as separate line items in these models or as an add-on to an existing item. The values themselves might be characterized as a single number, or modeled as a probability distribution in instances where M C S is intended to be carried out. It is also noted that in some cases risks are incorporated into the model by characterizing a project variable as a probabilistic variable (e.g., the Consumer Price Index (CPI)). The next sections of this chapter and the following two chapters describe the K R I S methodology that is to be used in the context presented above and is directed toward meeting the research objectives and addressing the research questions, and thus contributes to the effective management of risks on infrastructure projects. The discussion begins with an introduction to the set of definitions that have been adopted. Initially, the commentary is at the conceptual level, with detailed descriptions o f the various elements o f the approach, including details of its implementation as a prototype computer system, being set aside for elaboration in Chapters 4 and 5. 3.4 Definitions One of the challenges in discussing the topics o f risk and risk management is the absence of a consistent terminology. The International Organization for Standardization and International Electrotechnical Commission (2002) notes that the words used in different risk management contexts may vary, while Andersen (2001) states that "risk is unfortunately not a strict, well-defined term". The Project Management Institute Body o f Knowledge (PMI Standards Committee 1996) identifies several differences in 68 terminology that exist in describing various risk management functions. For example, the term "risk management" might be a reference to the overall process of managing risks, or be used to refer only to the combination of risk response development and risk response control tasks. A s noted previously, several authors have sought to organize information about risks through the use of mechanisms such as prompt lists, risk categorization schemes, and risk registers. In introducing these mechanisms, most often implicit definitions for the vocabulary used have been assumed. This approach can be acceptable within a single project, especially where interaction among project participants allows the opportunity to clarify meanings as to what is meant by a certain term such as a risk issue. However, when attempting to accumulate and apply risk-related information and knowledge using a computer-based methodology, greater precision in the terms used is necessary in order to ensure consistency among the populace o f captured information and knowledge. Consistent and explicit definitions o f concepts are particularly crucial as one attempts to address research question 2 and 3 related to modeling risks and the project context. The concepts w i l l allow the boundaries of the domain to be identified, i.e., set out what is to be modeled, and w i l l perform as the fundamental building blocks for the representation of risks, the project context, and the relationship between them. A number pf publications address the issue o f risk-related terminology. The Institution of C i v i l Engineers and the Faculty and Institute of Actuaries (1998) provide definitions o f terms in support o f the R A M P methodology, while the (PMI Standards Committee 1996) elaborates upon terms such as risk events and risk symptoms in providing guidelines for project risk management. The International Organization for Standardization and International Electrotechnical Commission (2002) have identified a set o f terms intended for use in developing risk management guidelines. In developing K R I S , a synthesis o f the definitions suggested in the literature has been used whenever definitions that suitably describe the concepts exist. Several additional definitions have also been introduced, primarily in support of integrating risk information and knowledge with the project context. The definitions are elucidated below. 69 3.4.1 Risk Issue The term 'Risk Issue' is used to refer to keywords (e.g., short term inflation rate, site conditions) that represent topic areas of direct relevance to a project, around which uncertainty or a lack of predictability may exist. A risk issue may result in multiple risk events, and consequent uncertainty in one or more project performance measures. Other terms used in the literature that correspond to this definition o f risk issue include risk factor, risk area (PMI Risk Management Specific Interest Group 2002), and risk source (Flanagan and Norman 1993). 3.4.2 Risk Event The term 'Risk Event' corresponds to the potential variability in a project parameter from its anticipated value (e.g., higher than expected inflation rate during the construction phase), or one or more discrete scenarios in which the possible states of nature that can be realized can be identified, but the one which w i l l actually occur as wel l as its outcome is not known with certainty (e.g., a slope failure occurs or not, and i f it occurs, its extent). A risk event can apply to the project as a whole (e.g., higher than anticipated inflation) -i.e., its extent o f influence is global, or it can be local in terms o f its immediate influence and hence treatment (e.g., a slope failure occurs while preparing the right of way at chainage 24+00 o f the highway). 3.4.3 Risk Drivers The answer to the part of research question 3 "How can the relationship between the project context and the risks o f a project be represented?" hinges upon the concept o f a risk driver. In general, the presence o f particular project or environmental components and their characteristics act as drivers o f the risk issues o f a project. A s described previously, aleatory and epistemic uncertainty can afflict the physical, process, organizational, and environmental components o f a project. The uncertainty can in some cases relate to the existence o f a component, for example, are endangered species present or not within the project site?, would restrictive noise by-laws be enacted?, and would the 70 project champion within the provincial legislature be re-elected? In other instances, uncertainty could exist as to the properties of a component, for example, the bearing capacity of soil, the anticipated average value of the core CPI within the project life, and the productivity rate of critical equipment. Should such uncertainty result in the possibility o f an event that could have an effect on project performance, a risk is said to exist, with the significance of risk being a function of the level of the uncertainty as well as the possible outcomes of the event. Thus, uncertainty, be it regarding the presence / absence of a component or regarding the properties of a component, is the fundamental cause of risks in an infrastructure project. In incorporating this phenomenon within K R I S , the concept o f a risk driver has been adopted. Components of the physical, process, organizational / contractual, and environmental domains, the presence o f which or characteristics o f which make a risk issue relevant to a particular project context are defined as 'Risk Drivers ' . For example, the risk issue 'labour shortage' is dependent on the economic situation in the region where the project is being built, among other factors. In a scenario in which the construction industry is at capacity, 'labour shortage' could be a significant risk issue. In this example, the state of the construction industry in the region, a component o f the economic environment of the project, drives the 'labour shortage' risk issue. Other examples include the process component 'dewatering' driving the risk issue 'property settlement', the regulatory environmental component ' B C heritage conservation act' driving the risk issue 'project approvals' and the consequent risk event 'delay in obtaining site alteration permit', and the component 'provincial government' having the attribute value 'minority' which describes its status in the legislature driving the issue Tack o f political w i l l ' . The explicit modeling of risk drivers is fundamental to the approach adopted in the thesis. It is also seen as something unique to the approach, given that the state o f the art provides cursory treatment at best with respect to modeling the components o f the project context that act as risk drivers. 1 3 As defined in Chapter 2, Risks are uncertain events or conditions that, i f they occur, have positive or negative effects on a project objective (Project Management Institute 2000). 71 3.4.4 Gateways The concept of a gateway is used in further refining the approach to modeling the relationship between the project context and the risks of a project. The large number of physical, process, environmental, and organizational components of an infrastructure project can be dispersed over sizeable temporal and spatial domains. For example, the process component 'cut and f i l l ' can take place at the locations 'east end approach' and 'west end approach' o f a bridge project. The placement of components in space and t ime 1 4 in such a manner is of importance as one attempts to consider possible combinations o f risk drivers that occur at a location and analyze the impact of their confluence on the risk issues of the project. For example, in the case o f the risk issue 'First nations artifacts', the relevance of the risk issue is heightened should the environmental component 'archaeological site' and the process component 'bulk excavation' be at the same physical location. Similarly, the risk issue 'fish migration' that is driven primarily by the environmental component 'salmon' would have particular significance for an infrastructure project that involves stream works scheduled concurrently with the salmon run. The common spatial location in the case o f artifacts, and the common spatial and temporal location in the case o f fish migration, provides grounds for risk drivers to act in synergy. The 'Gateway' concept models this phenomenon, and is defined as a common spatial or temporal frame within which multiple risk drivers are located. The explicit definition of the concept o f a gateway is a unique aspect of the K R I S methodology. The gateways act as filters through which drivers have to pass in order to have a bearing on a risk issue driven by another component. However, it is noted that being within the same frame does not necessarily entail synergistic behaviour among risk drivers in all instances and in some cases could be neutral in nature. 1 4 It is noted that in the case of organizational components the locations that are of importance are the temporal and spatial locations relating to the sphere of their involvement in the project, rather than the location of the organizational centre. For example, for a sub-contractor, the sphere of involvement could be the spatial location 'East end approach', and the temporal location 'Jan-Aug 2007'. 72 3.4.5 Performance Measures The impact of a risk is generally expressed by the multiplication of the likelihood o f a risk event and its consequence, i.e., impact of risk = likelihood x consequence (Construction Industry Research and Information Association 1996). Thus, of primary concern in risk management is the consequence that risk events have on project performance measures, both at the work package level and on performance at the overall project level. 'Performance Measures' can be defined as yardsticks used in evaluating the degree to which project objectives are met. Measures traditionally used in evaluating performance include time, cost, and quality (Cooke-Davies 2002), while Flanagan and Norman (1993) have also recognized the importance o f the effects of risks on safety and on operational needs (scope). Thus, in the methodology being described, the effects o f risks on time, cost, quality, scope, and safety have been considered. Also considered is revenue, a metric o f erstwhile importance in considering alternative modes o f procurement that typically involve a revenue stream to the concessionaire in the form o f performance payments or through direct user-pay mechanisms. It is also noted that the quality, scope, and safety ultimately get expressed in terms of time, cost, and revenue. Integrating over the basic variables at the work package level results in project level values for time, cost, and revenue. These in turn feed into global project performance variables which include measures such as project timelines, Life Cycle Cost ( L C C ) , capacity, N P V , IRR, and D S C R . 3.4.6 Risk Mitigation Measures A 'Risk Mitigation Measure' is defined as an action that seeks to reduce the probability and / or impact of a risk event to an acceptable value. A s described in the previous chapter, the measures include strategies such as redesign, alternative processes, insurance and contractual language. The relationships among the concepts defined above are shown graphically in Figure 13. Risk issues are driven by one or more drivers from the physical, environmental, process, and organizational / contractual dimensions o f the project. The particular combination o f 73 drivers of a risk issue is determined by the positioning of the components within spatial and temporal frames modeled as a series o f gateways. The nature or the form o f the drivers determine the risk events and associated impact upon performance measures that arise from a risk issue. In some instances, the probability o f occurrence o f the risk event can be controlled using risk mitigation measures, whereas in other instances the consequence of the event can be controlled. The risk events, albeit controlled by mitigation measures would directly affect project performance measures at the work package level and at the project level, and their impact would finally be expressed in terms o f deviations in measures such as the N P V or D S C R through which project feasibility or success is ultimately judged. It is re-emphasized that concepts such as risk issues and events have been defined utilizing similar definitions found in the literature. However, the explicit recognition of the concepts o f drivers and gateways is an incremental contribution and along with the other definitions acts as the foundation for answering research questions 2 and 3. 74 ( ^ Environmental Components V ) act as > f '~\ Physical Components V J C ~\ Process Components V J r , \ Organizational Components v ' J Time Risk Drivers < group i n . space and time. o H -< Risk Issues result in••> H ft f Gateways • f Mitigation Measures ) n O'. o Cost Revenue Scope Safety Quality Figure 13. Relationship between concepts 3.5 An Ontological Approach A body o f formally represented knowledge is based on a conceptualization: the objects, concepts, and other entities that are assumed to exist in some domain o f interest, as well as the relationships that hold among them (Genesereth and Nilsson 1987). Ontologies that are an explicit specification o f such a conceptualization (Gruber 1995) play the role o f a facilitator in the construction o f a domain model, for example, of the environment 1 5. In 1 5 A domain model of the environment refers to a representation of the characteristics of interest of the environment as a whole, and not to the environment of a particular project. 75 general, they provide a vocabulary of terms and relations with which to model a particular domain (Fensel 2003). The use o f ontologies in information and knowledge representation is well documented. Applications in risk management include GeRis, a tool for managing the risks associated with software development (Falbo et al. 2004). Examples of use relating to the construction industry include a feature ontology to support construction cost estimating (Staub-French et al. 2003), and an ontology developed for knowledge management in highway construction (Kashif 2003). The e - C O G N O S project (Wetherill et al. 2002) which is aimed at developing a set of tools that promote consistent knowledge management within collaborative construction environments also makes use of a construction specific ontology. Also of note are Industry Foundation Classes (International All iance for Interoperability 2005) which allow the specification o f shared information models of components and concepts occurring in the built environment through standard, object-oriented data structures. The process o f risk management has several characteristics that make an ontological approach appealing in developing a methodology to manage the information and knowledge associated with the process. Risks encountered on an infrastructure project can include risks o f a technical nature, environmental risks, risks related to project financing, as wel l as a host of other risks of a diverse nature. Thus, input from personnel with a variety o f backgrounds is required in identifying, quantifying, and devising responses to the risks o f the project. Additionally, the project teams put together within an organization are temporary, with the team being dissolved at the end o f the project (Disterer 2002). Thus, the teams for future projects would l ikely have a different composition. A specific conceptualization that allows project participants to have a shared image of the project, its environment, and its risks is therefore useful in eliciting information and encoding it within a computer system for use by different individuals during the project lifecycle. Re-use o f the information by a different set o f personnel on another project would also be facilitated by the adoption of an approach that incorporates the use o f a consistent vocabulary of terms and relations. In considering existing approaches, P R I M E (Tah and Carr 2001) recognizes the importance o f a consistent terminology in managing risks. P R I M E supports the build up o f a generic list o f risk 76 identifiers within the fixed categorization structure shown in section C.5 of Appendix C. It also supports the build up of a generic list o f remedial actions, which along with the risk list can be used in managing the risks of an individual project. Risk Radar (Integrated Computer Engineering Inc. 2002) allows users to build up a list o f mitigation measures, which can be re-used between projects and assist in ensuring consistency. K R I S builds upon these efforts by facilitating the development of a consistent vocabulary of terms and relations that encompass a much wider range of information, knowledge related to specific conditions that give rise to risks, as wel l as the relations between the project context and risks. Additionally, K R I S also aims for flexibility by allowing an organization develop and re-use a classification scheme and nomenclature of their choice. Given that an ontological approach is desirable, one is faced with a decision as to the structure of the ontology. Lassila and McGuinness (2001) have identified several notions of an ontology (see Figure 14) ranging from a controlled vocabulary to a frame-based approach that allows relations such as disjointness to be specified. A controlled vocabulary might consist of a catalog containing a finite list o f terms or a glossary containing meanings of the terms in addition to the terms themselves. Thesauri provide additional information regarding the relations between terms such as 'similar ' , 'narrower term', 'broader term', or 'synonym with ' . Informal hierarchies o f terms that do not require strict adherence to an is-a relationship are followed by formal hierarchies o f terms that demand adherence to a strict is-a relationship. The next item on the ontology spectrum is formal instance relationships that allow instances to be defined. Frames that allow properties to be defined are followed by frames with properties that have restrictions on what can f i l l a property. The spectrum goes on to include specification o f first order logic constraints between terms and disjointness. Goble and Shadbolt (2002) also identify several ontology representation techniques as shown in Figure 15. In addition to the paradigms identified by Lassila and McGuinness (2001), topic maps, Resource Description Framework Schema (RDFS) , and logic-based paradigms have been cited. Topic Maps as their name suggests groups information objects around topics. Relationships between topics can also be defined. R D F S describe rules for using Resource Description Framework properties by defining a domain vocabulary organized as a typed hierarchy, whereas logic-based approaches consist of primitive concepts and 77 properties that define relations between concepts. Defined concepts are built up using primitive concepts, properties, and constructors such as 'some' and 'only ' . The structure adopted in developing K R I S is described in the following section, which provides a conceptual overview of K R I S . Figure 14. Spectrum of Ontologies Identified by Lassila and McGuinness (2001) Figure 15. Ontology Representation Techniques Identified by Goble and Shadbolt (2002) 78 3.6 The Modelling Paradigm of KRIS The methodology developed to enable the management o f risk-related information and knowledge is based on a collection of models, herein referred to as 'V iews ' . The concept o f views, either in explicit or implicit terms has been pursued by a number of researchers (Fischer and Aalami 1996; Russell and Froese 1997; Russell and Udaipurwala 2004). Consensus on what constitutes the complete set of views required to provide a holistic treatment of a project has yet to be achieved, in part because most researchers are focused on a subset of project management functions. However, there appears to be consensus that at least two essential views correspond to the product and process models of a project. A n ensemble of five views is used in the methodology developed herein. O f these, four views are used to characterize different aspects of the context o f infrastructure projects. They are the Physical (what w i l l be built - the product), Process (how it w i l l be procured and constructed), Organizational / contractual (who w i l l participate in the project and their relationships), and Environmental (natural and man made environments in which it w i l l be built) domains. Risk information is modeled through a Risk view. The views that represent the project context and risks service two dimensions, one a project dimension in which an individual project is modeled for the purpose of risk management, and the other a dimension in which information and knowledge are modeled and cached in a project-neutral format in order to facilitate re-use on future projects. In the methodology, these two dimensions are identified as the 'Project Side' and the 'Standards Side' respectively. The K R I S methodology enables an organization to bui ld up generic domain ontologies or libraries for the five views on the standards side, and to re-use extracts from these libraries in building up the views on the project side as shown in Figure 16. 79 Augment standards with \ supplementary components defined by user Define standard components directly STANDARDS SIDE PROJECT SIDE . . . N.VA cm. USERS Define supplementary components to model project Copy applicable components to project side in modeling a project A Figure 16. Accumulation and Re-use of Information and Knowledge Related to a V i e w The question then becomes what representation technique best suits the domains that are to be modeled, i.e., the environment, physical components, process components, organizational components, and risks? In answering this question, recognition has been given to information and knowledge that relates to the views on a macro level, and the information and knowledge that relates to them at the micro level. A s an organization undertakes certain types of infrastructure projects, it gains information and knowledge on the components that typically make up the physical structure of the project type. Similarly, in executing projects within the same environment, such as a heavily developed urban area, one gains insights as to the environmental components that are typically present in such an environment. Information and knowledge of this nature that relate to the make-up o f a particular project dimension is considered as macro level knowledge in developing K R I S . Conversely, on a micro level, information and knowledge regarding individual components such as their characteristics which are 80 relevant to risk management and the risk issues driven by individual components need to be considered. Information and knowledge at the micro level can also relate to individual risk issues, such as the mitigation measures that are applicable to a particular risk issue. Furthermore, as described previously, in executing risk management on an infrastructure project, several tasks (particularly risk identification and response development) are carried out at a risk workshop (Morris and Simm 2000) that involve several people such as project managers, designers, operations managers, and financiers. Thus, the user of the risk model and the project context models is not an individual intimately familiar with their contents but a group of individuals whose interests or expertise relate to different parts o f the models. It is the information and knowledge generated by these users that is accumulated over a period of time on the standards side. Thus, a representation technique that is intuitive to a non-expert user is desirable. Also desirable is an approach that can support categorization of risks, given the advantages it provides such as aiding risk identification (Hillson 2003). In considering the options for structuring an ontology, approaches such as taxonomies, thesauri, and topic maps provide the ability to model the macro knowledge of the domains but are handicapped at the micro level due to their inability to model properties and the values they take on. Whi le logic and frames can model both types of content, frame-based systems provide intuitive, cognitively easy-to-understand, and scalable means for modeling a domain in a structured manner (Noy et al. 2004), features desirable for the K R I S methodology in which the risk knowledge w i l l be built up over time by its users. Thus, frame-based hierarchical models are used representing each o f the five views described on both the standard and the project side. In the models the components o f each view are listed in a hierarchical manner. The information and knowledge content relating to each component is modeled through a frame structured as a series o f several tabs. The standard libraries are intended to be developed on an ongoing basis as an organization is involved in a stream o f projects, possibly of different types, in partnership with a variety o f organizations, and within diverse environments. In building up a library, components can be added directly onto the standards side. Alternatively, i f in executing an infrastructure project, a component that is not already modeled within the standard 81 library of a particular view is encountered, the user has the option of copying the definition o f the component made in support o f the project, over to the standard library as an addendum. Figure 17 summarizes the ensemble of views on the standards side. Associations between components o f the risk view and the four project context views abet the modeling o f risk driver-risk issue relationships. In addition to the libraries corresponding to the five views, listings o f standard attribute identifiers, units, and linguistic terms can also be developed in support of the consistent use of terminology in identifying risks, project context components, their attributes, and values. Components can also be associated with supplementary information that is related, yet not core to their representations. A n organization can make use o f extracts from the standards side in developing the views corresponding to the context of an individual project (see Figure 18), as wel l as components defined anew in the absence of suitable standard content. Several strategies that make varying use o f the standard content are supported in developing the project risk view and are described in Chapter 5. The components o f the views created in this manner are made project specific by assigning values pertaining to temporal and spatial locations of the project. Subsequently, the contents of the project risk view serve as input to the project economic model, and in conjunction with the project context views can be used in analyzing the distribution o f risks over space, time, and corresponding responsibilities. 82 Constituents ' I i T i n i n o l o g y Standard Attributes Standard Units Standard Linguistic terms Standard Environmental View pi Templates defined using standard vocabulary • Component listing — Attributes Standard Physical View Templates defined using =j standard vocabulary 1 Component listing — Attributes Standard Risk View Risk issues / events denned within a Standard Risk Register using standard vocabulary — Applicable mitigation measures — Measures affected & methods of evaluating impact — Stakeholders affected / capable of managing risk Master list of mitigation strategies Master list of methods for evaluating impacts Standard Organizational / Contractual View Components denned using standard vocabulary Standard Process View Templates defined using standard vocabulary • Methods statements — Methods — Resources Supplemental Information -User actions ' , Develop Project Context Model • Extract & edit standard components • Define additional components / attributes • Assign attribute values J Develop Project Risk Register • Extract & edit standard components using - Associations - Judgment • Define additional components • Assign responsibilities, mitigation measures using - Encoded knowledge - Judgment • Assign probability values Figure 17 - Overview of the Standards Side Constituents Terminology Standard Attributes Standard Units Standard Linguistic terms Project Environmental View Listing of components applicable to project — Attributes/ values at locations Project Physical View Listing of project locations Listing of components applicable to project — Attributes/ values at locations Project Risk View Risk issues — Risk Events — Performance Measures affected — Probability values — Mitigation measures — Project parties responsible for risk Project Organizational/ Contractual View • Listing of components applicable to project — Attributes / values Project Process View Listing of components applicable to project — Attributes / values at locations Reports & Visualization ~ — — — LI'K ~ 1 ~ nm •—-— i -— • Distribution of risk issues over project participants / locations / processes • Probability parameters of risk events • Listing of risk issues and associated details such as ownership, mitigation measures, impact etc. Supplemental Information Project Records Figure 18 - Overview o f the Project Side The concept of re-usable libraries and the notions of a standards side and project side have been espoused by other authors in the past, e.g., Russell and Chevallier (1998), albeit for supporting functions other than risk management. Models that represent the physical, process, and organizational views (herein referred to as the 'three views' for purpose o f brevity) have also been developed by such authors within the RepCon research system at the University of British Columbia. In developing K R I S use was made of these representations. The use of these existing representations has allowed proof of concept of K R I S to be carried out while bounding the implementation effort required. Given that the structures have been developed for supporting other management functions such as planning and construction method selection, some non-uniformity in the interface and functionality has resulted from their use in implementing K R I S . These issues are discussed in Section 4.8 whereby the three views found within RepCon are discussed in further detail. However, as aforementioned, these views are based on the concept of re-usable libraries and that their use within K R I S did not entail any compromises in terms o f the concept o f the methodology. It is also noted that alternate models of the three views dedicated to supporting risk management function in a comprehensive manner do not exist, as illustrated by previous discussions on the treatment of the project context by existing approaches. The only contribution that is claimed with regard to the physical, process, and organizational views relates to the development o f the capability of modeling the driver-issue relationship. Aspects of these three views are described in thesis, albeit rather concisely, in order to provide the reader with a global view of the K R I S methodology. However, models for the environmental and risk view that allow users to build up a re-usable library o f components does not exist within RepCon or elsewhere and their development is a primary contribution o f the research. 3.6.1 Macro-level Structure o f the Standards The standard libraries contain generic components of the five views as shown in Figure 17. The process o f building up the libraries, the use of standard terminology in supporting 85 the libraries, and the process of extracting components in building up the project models is described in the following two chapters. In this section, the discussion focuses on the approach that has been taken in configuring the views on the standards side at a macro level. The standard libraries for the product, process, and environmental views have each been structured as a series of templates o f individual hierarchies as shown in Figure 19, while the risk view and the organizational view have each been formulated as single templates. The discussion here focuses on the environmental and risk views. fife Figure 19. Structuring of a V i e w as a Series of Templates Each template (T) of the environmental view is a subset of the universal set (S) o f components that make up a particular view, i.e. T c S. The rationale for stracturing the 8 6 view as a series of templates stems from practical and knowledge modelling considerations. From the perspective o f knowledge modelling, templates provide a direct means of encoding macro-level information and knowledge by system users. In taking a subset T from the universal set o f environmental components, knowledge as to what components typically constitute an environment o f a certain type can be encoded. For example, a template can represent the set of components that typically make up a mountainous environment, an urban environment, and so forth. Templates can also be devised to encode knowledge on the makeup of a portion o f the environment. A n example would be a template that defines the bird species of British Columbia. It is noted that the notion of creating and reusing templates is not a novel concept. For example, the use of Work Breakdown Structure (WBS) templates as the building block of a W B S of a new project is espoused by the Project Management Institute (2000). From a practical standpoint, browsing o f the standard libraries is made easier by having individual templates containing the hierarchies that relate to certain environment types, as opposed to having all components of a view organized within a single large hierarchy. This holds true especially as the number o f components of a view is fairly large, as is the case with the environmental view. Rankin (2000) and Koike and Yoshihara (1993) discuss concerns that can arise in visualizing extended hierarchies including the difficulty in maintaining a sense o f where one is in the hierarchy while attempting to see a sufficient level of detail. The template approach adopted in the research can overcome such difficulties to some extent via the grouping that occurs during the creation of templates. The grouping o f components into templates translates into a fewer number of components required to be viewed as opposed to viewing the totality o f components. A divergent approach has been taken in structuring the risk view. The standard library of the risk view is structured as a single hierarchy. The set o f risk issues relevant to a project arises out o f a consideration o f the particular combination o f physical, process, organizational, and environmental components that describe the project. Thus, i f one creates templates containing subsets o f risk components, the templates would out o f necessity relate to a combination o f project, environment types etc. (e.g., risks o f a divided highway in a mountainous environment, and risks of a divided highway in a 87 desert environment), rather than being simply related to a project type (e.g., risks of a divided highway) or environment type (e.g., risks associated with mountainous environments). A possible solution would be the creation of a set o f risk templates related to particular types of projects, procurement approaches, organizational structures, and environments, and the selective union of templates in representing the risks related to a particular context (i.e., risks of a divided highway u risks associated with mountainous environments). However, the primary disadvantages of such an approach is the inability to identify the specific risk drivers corresponding to individual risk issues. This renders the risk template as a mnemonic device unable to reflect changes made in corresponding context templates as the user edits their constituent components to reflect the conditions o f the project at hand. A more attractive solution is provided by considering the issue-driver relationship on a micro scale at the component level, modelled through associations between individual components of the risk view and components of the views describing the project context. This is described in later sections of the thesis. 88 4 Modeling of the Project Context The explicit recognition given to the project context, i.e., the context to which risks relate, is a primary theme o f the K R I S methodology. In this chapter, aspects of modeling the project context, epitomised by the physical, process, organizational, and environmental views, are described. The chapter provides details o f the approach that has been taken within K R I S in answering the research question 3, i.e., how can the relationship between the project context and the risks of a project be represented and how can the project context be modeled in support o f representing that relationship? Details of the approach taken in archiving content related to the project context are also described addressing some of the issues raised with regard to research question 5, dealing with information and knowledge content re-use between projects. In the description, extensive use has been made of screen captures from the implementation of the K R I S methodology as a computer tool within RepCon. The discussion starts with a commentary on the significance o f the environment in risk management followed by an analysis o f the approaches currently used in modeling the environment of infrastructure projects. 4.1 The Significance of the Environment in Project Risk Management The creation o f infrastructure can be thought of as the modification of the natural world in order to make it more suitable for a variety of human activities. It enables the smooth functioning o f modern society by providing it with needs such as roads, bridges, dams, tunnels, water treatment plants, and energy generation facilities. However, the process of creating infrastructure may result i n significant impacts being brought upon the existing environment. Examples include the physical disruption o f ecological systems caused by the construction of large dams across natural waterways and the impacts of highway construction on the stability o f fragile hillsides. It is noted that the impacts are not limited to the natural environment, as projects can also result in various socio-economic and cultural changes. 89 Conversely, environmental issues can have a significant impact on project success. In the U K , the construction cost of the Channel Tunnel is estimated to have increased by U S $ 1.4 bil l ion due to the modifications carried out to accommodate public concerns over environmental issues (Ofori 1992). Figures from the Northumberland Strait Bridge project indicate that the environmental costs were in excess o f 73 mil l ion Canadian dollars out of a total capital cost of approximately 800 mil l ion (Public Works & Government Services Canada and Strait Crossing Development Inc 1996). While in some cases such impacts can be predicted with certainty, in other instances the nature of the impacts might be unpredictable, or be of an uncertain magnitude, thus presenting significant risks to project success. Examples o f such risk events abound and include the discovery o f contaminated soil on site, changes in migratory patterns o f species that necessitate schedule changes, and natural disasters such as landslides, earthquakes, and floods. It is also noted that the risks are not limited to the natural environmental dimension. Uncertainty in economic environmental variables such as inflation, tax regime, and exchange rates can translate into risk events such as higher than expected debt service payments. Therefore, having an understanding of the project environment, and leveraging such an understanding in order to manage the uncertainties that can arise due to environmental entities can be considered as core to effective project risk management. 4.2 Current Approaches Towards Representing the Project Environment A s discussed in the previous chapters, the treatment o f the project context within current approaches towards managing risk information and knowledge is rather sparse. However, in most parts of the world, the environment of large infrastructure projects is characterized from the standpoint o f carrying out Environmental Impact Assessment (EIA) studies as part o f the approval process for such projects. Legislated guidelines determine the scope o f these studies which mostly relate to four categories of environmental components. They are: (i) Natural environmental conditions, (ii) Economic conditions, (iii) Social and health components, and (iv) Cultural and heritage components (Canadian Environmental Assessment Agency 2003). The components of 90 each o f these categories are identified in a baseline description of the environment, which is a core component in an E I A study report. The present state of the environment and its future state in the absence of the project are considered in the description (Glasson et al. 1994). In preparing a baseline description of the environment, the further sub division of the components that fall under each of the above categories into several sub-categories is a common practice. For example, guidelines for carrying out E I A studies in British Columbia suggest the use of ten sub-categories in characterizing natural environmental conditions (Province o f British Columbia 1995). They are Climate and air quality, Hydrology and water quality, Terrain and natural hazards, Soils and vegetation, Wildl i fe resources, Aquatic resources, Recreation and tourism resources, Forest resources, Agricultural resources, and Mineral and petroleum resources. These sub-categories are then further sub-divided, with individual components such as species of birds being listed under such a sub-sub-category. A similar approach is used in describing economic conditions, social and health components, and cultural and heritage components. Guidelines developed by other governments and agencies follow a parallel approach in specifying the manner in which the baseline environment should be defined. The Asian Development Bank for example, requires that E I A studies for projects funded by the bank include descriptions of the Physical resources, Ecological resources, Economic development, and Social and cultural resources in the vicinity of the project, with each of the four groups being made up of several sub-categories (Asian Development Bank 2005). Supplementary to a categorized listing of environmental components, E I A reports typically identify defining characteristics o f the components, as well as the values o f the characteristics. A n example characteristic would be the designation given by the Committee on the Status of Endangered Wildl i fe in Canada ( C O S E W I C ) to species of wildlife, which for example takes on a value o f 'threatened' for the Peregrine falcon bird species (British Columbia Ministry of Transportation 2004). Alternative approaches to describing the environment have been suggested by various authors in support of objectives other than E I A studies. Among them are models of the environment created in support of land use management. While being somewhat similar to E I A studies, these studies generally cover a much larger scope in terms o f the 91 study area. The approach taken in describing the environment in such studies mirrors the hierarchical characterizations employed in E I A reports. The environment is typically broken down into several major categories, which are then sub-divided. Environmental components are listed under the subdivisions. For example, a study carried out in Western Australia to guide the management o f existing and potential land use changes in a coastal area considers the Natural environment, Heritage, and Natural resources as the three main categories that make up the study environment (Sinclair Knight Merz Pty L td 2003). O f these, Heritage is subdivided into the Indigenous, European, and Maritime sub-categories, with individual heritage sites being listed under each sub-category. A similar approach has been used in describing the Natural environment and Natural resources. A characterization o f the environment in terms o f eleven factors has been developed by Hughes (1989) in recognizing the implications o f the environment on the organizational structure o f projects. The factors that have been identified with particular emphasis on the environments of building project include: (a) Cultural - Describes society's acceptance or tolerance of certain modes o f behaviour. (b) Economic - Description of general economic activity as well as economic resources available for the project. (c) Political - Government policy and effect of political decisions on the project. (d) Social - Social requirements for the project. (e) Physical - Site conditions such as weather. (f) Aesthetic - Considerations related to the aesthetics around a project. (g) Financial - Avai labi l i ty / restrictions o f monetary resources. (h) Legal - Legislation such as building regulations that affect the project activities. (i) Institutional - Influence that professional institutions can have over consultants, (j) Technological - Technology available to do the work. (k) Pol icy - The attitude towards environmental influences within the project organization. In addition to models o f the environment developed for a specific task such as an E I A , generic taxonomies o f environmental components have also been developed for some 92 dimensions of the environment. Among these is the biological classification of organisms which relates to the grouping and categorizing of extinct and l iving species of organisms (Gotch 1996; Jeffrey and Systematics Association 1977). The organisms are placed into a layered hierarchy of groups, o f which Domain is the most general, followed by Kingdom, and Phylum for animals and Divis ion for plants. These are followed by Class, Order, Family, Genus, and Species. In some instances, sub-levels, such as Suborder may be used. Individual organisms are identified using their Genus and Species 1 6 . A s an example Sciurus carolinensis, is the identifier of the Eastern gray squirrel, based on its taxonomic classification (Genus - Sciurus Species - Carolinensis). Classification schemas also exist for describing geographical features. The Canadian Counci l on Surveys and Mapping standards for topographic feature classification is one such standard (British Columbia Ministry of Sustainable Resource Management 2005). In this scheme, features are grouped under a set of hierarchical classes and categories. Examples o f classes at the top level of the hierarchy include Designated area, Building, and Hydrography. These are divided into categories, such as Inland water body and Wetlands under the Hydrography class. Individual components such as Lagoon, Lake, and Pond are listed under such categories. A s illustrated above, several approaches and guidelines towards representing the environments o f projects are in existence, o f which models that support E I A studies are of special significance due to their widespread use. However, it is observed that while standards for classifying certain subsets of environmental components exist in isolation, an international, national or regional standard that can be used to describe or model the complete environment o f most projects does not exist. A n extensive review o f E I A reports for major projects in Canada and elsewhere reveals that while there can be some similarities, there are always notable differences in the terms o f the classification schema and the semantics used to describe the environment for individual projects. This holds true even in jurisdictions where guidelines have been published, as their primary role is to serve as a tool that assists project stakeholders in understanding and carrying out the E I A process, as opposed to providing strict procedures and terminology that demands In the case of sub-species, the sub-species name is added. 9 3 adherence. It is also observed that most environmental descriptions used in practice adopt a hierarchical structure as illustrated by the examples given above. The hierarchies generally tend to be made up of three levels with the odd exception being up to a maximum o f five levels. 4.3 Representing the Environment in Support of Risk Management In devising a modeling paradigm for representing the environment in support of risk management, consideration needs to be given to issues raised previously such as the lack o f standards in characterizing environmental components and the diversity of the components that need to be represented. Consideration also needs to be given as to the role desired o f the computer versus the role o f the user, a debate epitomised in research question 1. Should flexibility be provided for users to develop a model of the environment based on a nomenclature o f their choice, or should the model be pre-defined and hard-coded limiting the role of the user to selecting entries from the constrained set? The latter option offers ease o f ensuring consistency as the user is required to adhere to a constrained set o f entries and also allows interfaces to be moulded to suit individual components that are diverse in nature. However, the number of environmental component that are likely to be encountered as an organization undertakes projects in a variety of environments is l ikely to be significantly large hindering the pre-definition o f each and every components within a computer system, prior to the organization actually encountering them. Furthermore, the lack o f standards in identifying a large segment of the environment makes it unlikely that a hard-coded nomenclature that is attractive to a breadth o f organizations could be conceived. Thus, in developing K R I S the philosophy that has been adopted is to provide an architecture or a framework that allows an organization to develop a model o f the environment based on a nomenclature of their preference. Next, the details o f the modeling approach based on such a philosophy is presented, starting off with a definition o f the environment. 94 4.3.1 The Environment Defined In modeling the environment within K R I S in support of risk management, the 'Environment' has been defined as the physical, social, economic / financial, political, and regulatory surroundings of a project, thus encompassing the dimensions considered in E I A studies as well as well as other surroundings that can be o f significance for project risks. It includes components that are present within the project site and its vicinity, as wel l as components that would occur within the area in the future, which are not a direct result o f the project. O f these, the physical surroundings refer to both natural and man made entities present in the study area. Natural entities include l iving organisms and inanimate objects such as geological features and natural resources. M a n made entities include existing structures such as buildings and other infrastructure. The social surroundings take into account factors such as the demographic profile in terms of age, income, etc., cultural characteristics, and the state o f services such as health and education. These factors can be of particular importance with regard to risk issues related to the project revenue function and issues related to stakeholder opposition. Economic and financial surroundings relate to conditions such as inflation, lending rates, exchange rates, existing technology, and the labour market. Federal, provincial, and local governmental characteristics are considered in the political surroundings. Expropriation and the cancellation of projects brought on by shifts in political power are among risk issues that are driven by the political dimension o f the environment. Regulations relating to taxation, environmental protection, labour relations and safety, and municipal by-laws are among the factors that fall under the regulatory surroundings and can serve as drivers o f legal risk issues and revenue uncertainties due to changes in taxation. 4.3.2 The Environmental Breakdown Structure A s outlined in the previous chapter, the modeling approach towards the environment relies on the use of a domain ontology or library on the standard side, extracts from which are used in building up the environmental model of an individual infrastructure project. The library of environmental components as wel l as the environmental models of individual projects are structured as a hierarchy, a form that mirrors current practice in 95 representing the environment on infrastructure projects, albeit for functions other than risk management. For example, as described earlier in the chapter, models adopted in E I A studies as wel l as the standards available for segments of the environment such as species o f organisms are hierarchical. The use o f a similar representation paradigm within K R I S would simplify the extraction of relevant information from the output of E I A studies which are the primary repository o f environmental information on a project. Moreover, hierarchical structures allow flexibility in the level of detail at which the environment can be represented on an individual project. Flexibil i ty can be considered important as it allows a model to be developed with the information available, allowing reasoning about risks to be carried out at various stages o f the project. For example, in a preliminary assessment o f project feasibility and risks, a coarse model that makes use o f a shallow hierarchy may be used for representing the environment in order to identify the risks driven by the components for which information is available. A s more information becomes accessible regarding the project's environment, and as decisions are made as to the pricing o f risks and their allocation, a more detailed and slightly deeper environmental hierarchy would be required to assist the risk management process. A hierarchical approach also facilitates inheritance and aggregation o f properties. Inheritance enables attributes that are common to a particular group o f components to be defined within components at a higher level in the hierarchy and to be inherited by components at lower levels, allowing the speedy setup o f an environmental model, and assisting in ensuring consistency and adherence to standard terminology in defining the attributes. It holds special significance for modeling the environment as instances where components o f a group share many common attributes abound. 'Breed within area?' is a property o f importance for most animal species components, while 'Current value' is a common parameter of interest in describing economic components such as inflation and exchange rates. Aggregation facilitated by hierarchies can also be a useful property in instances such as when the number o f inhabitants spread out within several communities need to be aggregated to determine the total populace within the project footprint. However, a hierarchical representation is not devoid of drawbacks. Difficulties can arise in ensuring that components are organized in such a manner that they are not duplicated within a single hierarchy, and in dealing with multiple inheritance. 96 The discussion above illustrates the rationale behind the selection of a hierarchical model in devising answers to the research question dealing with representing aspects of the project context. A five-level hierarchy termed the Environment Breakdown Structure (EBS) has been adopted in developing the domain ontology herein referred to as the Standard Environmental Library (SEL) , as wel l as in modeling environments of individual projects. A s stated previously, a three-level hierarchy is typically used in E I A studies to model components of the environment. The number of levels adopted within K R I S provides sufficient flexibility for modeling at a greater level of detail i f required, with the cap of five levels reflecting a belief that very highly detailed models are not indicative of day to day practice, the quality of data available, and the resources typically available for building up such a model. In aligning with the philosophy o f providing an architecture that can be used in modeling the environment, the E B S allows a user to define environmental components at each level of the hierarchy with the components at various levels in the hierarchy reflecting 'a part o f relationship. It is re-emphasized that the environmental view consists o f components that are disparate. For example, components o f the economic environment are primarily metrics that have resulted from economic theory. They are quite different in nature than components such as birds and streams that have a physical presence. Thus, the definitions that have been adopted for the various levels o f the E B S have been moulded in a flexible manner that allows them to model components from different environmental dimensions. The five levels o f the E B S hierarchy are: Environment : Represents the totality of the environment, and serves as an umbrella under which all categories o f components as wel l as the components themselves can be defined and described. It serves as the root node of the E B S hierarchy. Class and Sub-class: The class and sub-class levels are used in categorizing environmental components. In illustrating aspects o f the K R I S approach, five classes have been used. They are the Physical, Social, Economic / Financial, Political, and Regulatory classes. However, as aforementioned, K R I S allows an organization to define classes and other components based on a nomenclature and 97 categorization scheme of their own choice. The sub-class level of the E B S hierarchy is used to further categorize components, i.e., to separate a subset of environmental components within a class. Examples include, Zoological sub-class and Geological sub-class within the Physical class, and Macro economic factors and Micro-economic factors sub-classes within the Economic / Financial class. Ent i ty and Sub-entity: The entity and sub-entity levels are used to represent individual environmental components, that are distinguished by the presence of attributes that describe the nature of the component and which can be instantiated by assigning values to such attributes. Allowance for two such levels, i.e. entity and sub-entity has been made primarily to allow flexibility in the level at which the modeling may be carried out at different stages o f an infrastructure project, and between different projects. In developing a S E L as wel l as in modeling the environment of an individual project, the user would define components at various levels in the E B S hierarchy, a process explained in more detail in following sections. The use of each o f the four lower levels is made optional within the E B S i n facilitating flexibility. Thus, a user can simply define and make use of an environment-class taxonomy, use a shallow environment-entity model of components and their properties disregarding any sort of classification, or use all five levels in developing a comprehensive characterization based on their requirements. 4.3.3 The Standard Environmental Library To recap, the E B S is a hierarchical framework that provides the architecture for modeling individual environmental components as well as component categories. In building up the Standard Environmental Library (SEL) , a user would utilize this architecture to model components in a project-neutral format, for example to define a western grebe at the sub-entity level with the attribute 'breed within area?'. The S E L is a collection o f components defined in such a manner, with the objective being to allow a user to extract and re-use the component definitions from the library on occasions that the components are 98 encountered on various projects. The ability to use S E L components in this manner not only saves the user the trouble o f re-defining the component from scratch on every project it is encountered, but also ensures consistency in the terminology used in identifying components and their attributes. A s discussed in Chapter 3, the standard side of the environmental view is structured as a series of templates, with each template corresponding to a particular type of environment such as ' B C Interior - Lacustrine Environment' as shown in Figure 20. The creation of templates is an attempt to model information and knowledge related to the make-up of a particular environment and in some instances, templates may also be defined at the class or entity level o f the E B S where such a distinction is justified. A n example would be a template at the Class level describing the 'Physical environment -North American Prairies' (see Figure 21) that limits itself to describing the physical features and organisms in a region where the political, regulatory, and socio-economic conditions can vary widely between the provinces and states. The templates consist of a hierarchical listing o f components, with each component being mapped onto a specific level o f the E B S . For example, in the template shown in Figure 20, the totality o f the ' B C Interior - Lacustrine Environment' is mapped onto the environment level o f the hierarchy. The 'Physical ' , 'Socia l ' , 'Pol i t ica l ' , 'Economic ' , and 'Regulatory' sectors of the environment are mapped onto the class level, followed by entries at the sub-class level or in some instances at the entity level. Components such as 'River Otter' that are part o f the 'Mammals ' component modeled by a node at the entity level, are listed at the sub-entity level o f the hierarchy. 99 5: File Project"_View - btjrdjrds Standard EB5 Window Help _^  Template Tree Structure Description . Physical Environment - North American Prairies MASTER EBS BC Interior - Lacustrine Environment US Southwest - Desert Canada -. Urban Environment Jype Class Environment Environment Environment Environment i l l Ready FJC Interior - Lacustrine environment ES ROOT Environment BC Interior - Lacustrine Environment B PHYSICAL Class Physical Environment i {+3 - GEOLOGY Sub-class Geology-i m SEISMICITY Sub-class-Seismic Activity i BD- CLIMATOLOG' Sub-class Climate IS • DESAREA Sub-class Designated area i a BUILDING Sub-class Existing Building I. 51 STRUCTURE Sub-class.ExistingStructures i P3ROADRAIL Sub-class Roads and Railways . i ffi UTILITY Sub-class.Utilities,, i [±1 HYDROGRAPH :5ubrdass Hydrography. i SS HYPSOGRAPH Sub-class Hyposgraphy i it BOTANY Sub-class Botanical Components ." • i • E3-ZOOLOGY . -Sub-class ZoologicalComponents . . El-BIRDS Entity Birds i S--MAMMALS Entity Mammals i-CACANADENS-Sub-entity Castor canadensis - Beaver LO«NADH>j5TSublSitft)' Lontra canadensis Rp,erOttei ' i-MUVISION • Sut>entity Mustela vision - Mink i i-ONZIBETHIC Sub-entity OndatrajibetHcus-Muskrat J : ; REMEGALOTISub-enbty Reithrodontomys'megalotis- Western Harvest Mouse a AMPHIBIANS Entity:Amphibians B.REPTILES Entity Reptiles . . . . -'. ' H - F I S H Entity Fish • SOCIAL Class Social Environment " '• . &T ECON -Class EconomicEnvironment •FH - POLITICAL.. Class • Political Environment B REG : Class Regulatory Environment . - B CAN •' Sub-class Canadian Legislation ' CANNAV Entity Canadian Navigable Waters Protection Act . pCANENV. Errtity.:Canacban Environmental Assessment'Act i CANFISH Entity Canadian Fisheries Act CANWATER • Entity Water Act B BC .. -.. Sub-class-Provincial Legislation-BC. •• i i B C E N V A S ; Entity BC Environmental Assessment Act >••• BCHERIT ..Entity BC Heritage Conservation Act B BCEMGT Entity BC Environmental Management Act . .• WATQUAL Subrentity. BC Approved.Water Quality Guidelines . • . B MUNICIPAL-Sub-dass Municipal By-laws - : . • NOISELAWS Entity Noise By-Saws Figure 20. A Template Defined at the Environment Level o f the E B S Hierarchy 100 ' f i F i l e Project.Viewl'lieftinla'e^'i?'." " Standards Standard_EB5 „ Window Help Template Tree Structure Description' Type Physical Environment - North American Prairies MASTER EBS BC interior - Lacustrine Environment US Southwest-Desert Canada - UrbanEhvironmeht Class Environment Environment Environment Environment H i p Ready j? mt... Physical Environment - North Amer!cap Prairies • r.._ . _ ._ B- ROOT Class Physical Environment - North American Prairies R GEOLOGY Sub-class Geology i H- SOIL Entity Soil 5 SEISMICITY Sub-class Seismic Activity B CLIMATOLOG Sub-class Climate | TEMPARAT Entity Temparature ! PRECIP Entity Precipitation WIND Entity Wind Conditions : El- DESAREA Sub-class Designated area • AA10550000. Entity Farm ; AA10650000 Entity Feedlot: :AA23150000 Entity Ranch • I-AD01000000 Entity Archaeological Area !-AFi460b0b0 .Entity :lhdian Reserve !--AFH950bbd Entity Jaiicompiex !•AG09700p00 Entity Electrieppwer generation complex : AL20150130 Entity Park- Municipal : ; B BUILDING Sub-class Existing Building r 6B01350000 Entity Bank ; BB14050000 Entity Hotel/Motel/Tourist lodge/Inn ' BE26000000 Entity School : BL17000000 Entity Marina • BM4350000 Entity Cathedral 6 STRUCTURE.. Sub-class. Existing Structures ; B ROADRAIL Sub-class Roads and Railways i DA24950000 Entity Road (Gravel Divided) iDA25000000 - Entity Road (Gravel Undivided) •!. S DA25050000 Entity Road (Paved Divided) : DA25100000 Entity Road (Paved Undivided) •DD03250140 Entity Bridge (Roadway) 7 Floating l-J UTILITY Sub-class Utilities EA03800000 Entity Cable B EA21400000 Entity Pipeline ^A21400270 Sub-entity Pipeline - Natural gas EA21400470 Sub-entity. Pipeline - Sanitation E HYDROGRAPH Sub-class Hydrography EJ HYPSOGRAPH Sub-class Hyposgraphy B BOTANY : ••- Sub-class Botanical Components . B- ZOOLOGY: Sub-class:ZoologicahComponents , Sv- BIRDS . Entity Birds &]• MAMMALS Entity Mammals ffi AMPHIBIANS Entity Amphibians S REPTILES Entity Reptiles L+J FISH Entity Fish vl M Figure 21. A n Environmental Template Defined at the Class Level of the E B S Hierarchy 101 In implementing K R I S within the RepCon system, a split interface is used with the templates being listed on one side, while the expandable hierarchy o f a selected template is shown on the other side. Components can be added to a hierarchy by using the ' A d d at same level ' or ' A d d at sublevel' commands which are displayed when an existing component is right-clicked as seen in Figure 22. Components can also be copied between templates by using the 'Copy standard component to same level ' or 'Copy standard component to sublevel' commands. Templates themselves can be added by using the ' N e w ' command from the 'Standard E B S ' menu seen in Figure 23. J5j File_ pr"0)55y^ • femgfe):pL|few/ Standards Standard EBS "W^dow_JHelp_ . '& l i t e l^lii IJl^^El^lflJ^li iJNikl^J^ SIT? Template Tree Structure Description LlYGS-Physical Environment - North American Prairies Class MASTER EBS BC Interior - Lacustrine Environment. • US Southwest - Desert Canada - Urban Environment Environment Environment Environment Environment IjCana da^ Urban E n viron men t Add at samelevel Add at sublevel Copy standard component Copy standard component Delete Edit to same level to sublevel Ready mm Figure 22. Edit ing the Environmental Component Hierarchy 102 |5[File'l~Pro]ect_View Xemp'cjLo.yiewi -Standards, Template Description Physical Environment - North American Prairies Class Enviro Record List • j Environment MASTER EBS MASTER EBS BC Interior - Lacustrine Environment US Southwest - Desert cjEnvircv Window Help Component • Class Unit Atribute Report SIMM a AddistandardiEBS;template, - * *| Description' (Canada - Urban Environment Type: f - • i l l 'Environment Class • Entity. OK- ..... •! Cancel Figure 23. Adding Environmental Templates 103 4.3.4 Issues of Consistency in the Development of the Standard Environmental Library The discussion above has illustrated the process that can be adopted in building up a hierarchy o f environmental components as wel l as in creating sets o f such components organized into templates. However, the solutions rarely involve the simple selection o f a modeling methodology in devising answers to research questions such as how can the project context be modeled in support o f representing that relationship? Almost always, the answers lie in also addressing several nuances that are associated with the question, with the issue of maintaining consistency being a case in point. A s has been emphasized previously, the S E L is intended to be developed on an ongoing basis with environmental components that have not been previously encountered and modeled being continuously added as an organization gains exposure to various projects. Primary among the issues that need to be given consideration in developing a S E L in this manner is a need to ensure consistency in identifying the components within the S E L . Whilst the creation o f templates corresponding to different environments affords the opportunity o f modeling knowledge related to the make-up o f various environments, it also poses challenges to ensuring consistency. The same component that is present within two templates could inadvertently be assigned two different identifiers, leading to confusion should extracts from both templates be used in modeling a specific project. Additionally, the properties of the components need to be maintained within two or more different templates further increasing the likelihood of inconsistencies. In avoiding such difficulties in building up the S E L within K R I S , the components w i l l first be added to a 'Master Environmental Breakdown Structure' ( M E B S ) containing the totality o f the components modeled within an organization such as the one shown in Figure 24, extracts from which w i l l be used in building up templates specific to certain environment types. While functionality for creating templates and copying components between them has been incorporated within the current implementation of K R I S , the ability to create filtered images o f the M E B S that automatically reflect changes made to the M E B S has not been incorporated, and is among the future work anticipated. 104 u '5, File Pro]ect_View -Standards, Standard EBS, Window Help * r -Template j Tree Structure Description.: JEYPJI MASTER EBS Physical Environment - North American Prairies Class MA5TEREB5 Environment BC Interior - Lacustrine Environment Environment US Southwest-Desert Environment Canada' 1 Urban Environment Environment < Ready : ENV Environment MASTER EBS Ei PHYSICAL Class Physical Environment fi GEOLOGY Sub-class Geology i l SEISMIClTY Sub-class Seismic Activity B CLIMATOLOG Sub-class Climate S-DESAREA Sub-class-Designated area >; BUILDING Sub-class Existing Building S STRUCTURE Subclass' Existing Structures ' SJ ROADRAIL Sub-class Roads and Railways ! v, UTILITY Sub-class Utilities • R HYDROGRAPH Sub-class Hydrography S HYPSOGRAPH Sub-class iHyposgraphy Ul BOTANY Sub-class Botanical Components. i B-ZOOLOGY Sub-class Zoological Components ;-; * BIRDS Entity Brds . . . : ACCOOPERI Sub-entity Acapiter cooper'- Cooper's Hawk ACGENTIU5 Sub-entity Accipiter gentilis-Northern Goshawk !• - ACSTRIATUS Sub-entity Accipiter stnatus - Sharp Shinned Hawk ; AEOCCIDENT. Sub-entity Aechmophorus occidentals - Western Grebe . E • ARHERODIAS Sub-entity' Ardea herodias -Great Blue Heron ; BOLENTIGIN Sub-entity Botaurus lentigmosus - American Bittern i :-CLHYEMALIS,Sub-entity. Clangula hyemalis-Oldsquaw . :• CYBUCCINAT: Sub-entity Cygnus buccinator - Trumpeter. Swan :-FAPEREGRIN Sub-entity Falco peregrmus - Peregrine Falcon •~-HALEUCOCE :Sub-entity Haliaeetus leucocephalus - Bald Eagle ! ICVIRENS Sub-entity Icteria wens-Yellow-breasted Chat-; - LACALIFORN Sub-entity Larus californicus - California Gull i MELEWIS 5ub-enUty Melanerpes lewis r. Lewis' Woodpecker. . i - MEPER5PIC Sub-entity Melamtta perspicillata - Surf Scoter. ' i ; OTKENNICO Sub-entity Otuskenmcottii-WesternScreech-owl 'PEERYTHRO-Sub-entity Relecanus erythrorhynchos - American WhitePelican B MAMMALS : Entity M a m m a l s . i-ALALCES : Sub-entity Alces alces - Moose -: 4 ANPALLIDUS Sub-entity Antro20us paWus-. Pallid Bat i .APRUFA SubTentity.Aplodontiarufa- Mountain Beaver . I • H BAASTUTUS Sub^entity. Bassariscus astutus - Ringtail CALATRAN5: Sub-entity: Canis latrans -Coyote -CALUPU5 Sub-entity. Canis lupus-Gray Wolf. : : CACANADENS Sub-entity Castor canadensis - Beaver , ;:-CECANADENS-Sub-entity Cervus canadensis,- Elk - . . ::.LOCANADENS Sub-entity Lontra canadensis-River Otter . . . - . . MUVISION Sub-entity Mustela vision - Mink ; : ONZIBETHIC Sub-entity Ondatra zibethicus - Muskrat ; • RATARANDUS Sub-entity Rangifertarandus-Caribou . •~ REMEGALOTI: Sub-entity: Reithrodontomys megalotis - Western Harvest Mouse (B AMPHIBIANS: Entity Amphibians .; :+VREPTILES Entity Reptiles .. .:':-- . ; . .- ;.; FISH Entity Fish • " • E) SOCIAL- - Class: Social Environment - ; -S ECON.: Class Economic Environment .:.:: - • • : - - : : - . . - . • [^POLITICAL Class: Political Environment . • a REG : Class Regulatory Environment Figure 24. Master Environmental Breakdown Structure Another issue o f interest relates to the identifiers used by an organization in building up a S E L . The review o f current approaches to environmental modelling presented earlier in this chapter illustrated that standards for characterizing environmental components occur 105 only in isolation. Thus, the K R I S approach relies on an organization characterizing components using terms commonly adopted within that particular organization, alongside the standards that exist for some parts of the environment such as l iving organisms and topographical features. In the examples developed in support o f the current research, organisms have been identified using standardized scientific names of species. The Canadian Council on Surveys and Mapping standards ( B C Ministry of Sustainable Resource Management 2002) on topographic feature classification (e.g., GA24850000 -Stream / River) have been adopted in the naming of topographical features. However, it is re-emphasized that K R I S provides an architecture that is flexible in allowing an organization model the environment based on categories and identifiers, i.e. a nomenclature, o f their choice. Whi le the significant set o f components that have been modeled by the author in demonstrating the functionality o f K R I S can be very useful to an organization in developing a S E L , the nomenclature is merely illustrative and not a restriction that demands adherence. In addition to maintaining consistency in identifying components, uniformity in identifying attributes and in assigning linguistic values is desirable. Such uniformity can assist in deriving insights from the characterization o f the environment such as the components that have been assigned a certain value for a particular attribute, an exercise that is difficult should the attributes be identified differently among various components. The approach that has been taken in refining the modeling solution to handle such issues is discussed in the following section. 4.3.5 Properties of Environmental Components The risk issues that are driven by a project component are in some instances dependent upon the characteristics of components and not simply on the presence of the component within the project context. For example, the risk issue 'Endangered species' and resultant risk events such as 'Species required to be relocated' would be relevant to the project only i f any of the species within the project boundary are classified as endangered. Thus, a taxonomy of environmental components alone w i l l not suffice in supporting the task o f risk management. It also becomes necessary to define both quantitative and qualitative 106 attributes which are of significance to the risk management process. A s already emphasized, the environmental dimension of a project contains components that are diverse ranging from physical components such as caribou to economic components such as the CPI . The attributes of interest of these components such as the designation given by C O S E W I C to caribou, and the five-year moving average of the C P I tend to be quite different. Therefore, in implementing K R I S within the RepCon system, flexibility has been provided for user definition of properties in adding individual components to the S E L , as opposed to the hard coding o f a limited number of attributes. The attributes can be accessed by selecting the 'Edi t ' command from the list o f commands that pop up when right-clicking components of the hierarchy, as shown in Figure 25. 107 5' >^imuia.!aia'i:G?ji^:slital^iai u B-• ENV Environment OLB Project Environment L= PHYSICAL Class Physical Environment gj GEOLOGY Sub-class Geology B-SEISMICITY Sub-class Seismic Activity DESQiAKEgEptiaiDeagh Earthquake 13 CLIMATOLOG Sub-class Climate jj DESAREA Sub-class Designated area .+! ROADRAIL Sub-class Roads and Railways ; S" HYDROGRAPH Sub-class Hydrography, BOTANY Sub-class Botanical Components B: ZOOLOGY Sub-class Zoological Components B" SOCIAL Class Social Environment EB-- ECON Class Economic Environment E POLITICAL Class Political Environment B-- REG Class Regulatory Environment. Add at same level Add at sublevel Copy standard component to same level Copy standard component to sublevel Delete " • • E d * . ; * ' " " , v * EditiEBS,compo'rienti--SJ-{, • AHnbutes j Value- ; Standard EBS Recoids | Risk Issues / Events ] Project Records ] Memo j featl^ENV PHYSIGAbSEISMiCITy. j f o d e l f b E S Q U A K E ^ D T x r i p t i c n [Be.ign Eaithquak. Type Atliibute Description Near Field Event Magnititude Near Field Event Radius Far Field Event Magnitude Far Field Event Radius •••• Inherited Attribute NO NO NO NO NO B / Q / L . _Umt Q Y Q RICT Q km Q RICT Q km V Inheiit attribute definition from above level Add Delete • • i i i Edit Figure 25. Accessing Attributes o f Environmental Components 108 In K R I S , three types of component attributes have been considered, which are Quantitative, Linguistic, and Boolean. A distinction has been drawn between these types for the reason o f enforcing a degree of consistency in terms of the values that an attribute can take, and where applicable, to ensure attribute values are expressed in the same units throughout the system. Quantitative attributes are defined such that they can take on any numerical value or be defined as falling within a range of numerical values. The values o f linguistic attributes can take on any combination of characters and is used to model attributes that are more appropriately described qualitatively. Boolean attributes have been defined to allow for the case when an attribute represents a quality that can take on only two distinct values such as 'true' or 'false', or 'yes' or 'no' . The dialog box used in entering the details o f attributes is shown in Figure 26. In addition to details regarding the attribute name and the units (in the case o f quantitative attributes), facility is also provided for adding standard values for the attribute. The standard values are a set of reference values that can be used as a benchmark in assigning a value to the attribute. For example, caribou are typically a migratory species 1 7, and thus a standard value of 'true' could be assigned against the attribute 'migratory?' to provide a reference in assigning a value to the attribute on a particular project. In this case the standard value functions in a manner very similar to a default value, the difference being that the user has to manually assign the standard value in modeling a particular project, a measure adopted to prevent assignment o f default values by mistake. Standard values can also be used to model the user's knowledge regarding particular constraints that may exist with regard to attribute values. 1 7 A n exception are the boreal caribou, which are found in northern and northeastern Alberta 109 ueiStfiiw Jieiiiplale- MASTER EBS Path: E NV. PHYS ICALZO 0 LO GY. MAM MALS. Attribute JMigratory"? Clasi ! • Value Type Boolean Standard Value Relation Condition S tandard Value 1 • t Standard.Va' EQ True Add Delete Edit : • T — "OK Cancel Wm Figure 26. Details of Attributes of Environmental Components While the facility for user definition o f properties is useful, it does pose challenges, especially in ensuring that attribute identifiers are consistent among components that have the same attribute. A s an example, the C O S E W I C classification is an attribute o f importance to both mammal species and bird species. Adopting a common identifier for the attribute in both instances can assist in enabling a shared understanding among the individual users o f the methodology, as well as facilitating the development of search and retrieval mechanisms. The use of inheritance is a strategy that can be applied in order to achieve consistency in such instances. Common attributes can be defined at higher levels in the hierarchy and be inherited downwards, also reducing the burden on the user o f defining such attributes multiple times. The functionality for inheriting attributes has been built into the prototype system, with the user given the option o f 'Inherit attribute definitions from above level ' (see Figure 25). It is noted that selective inheritance and multiple inheritance is not enabled in the current implementation. The use o f inheritance in ensuring consistency, however is not feasible in instances where components occur in disparate parts o f the hierarchy. Thus, in K R I S the 110 development of a standard set o f attributes that can be used in defining the properties of environmental components is facilitated. The standard attributes set is intended to be developed over time in parallel to the development of the S E L . Figure 27 illustrates the facility provided within K R I S for developing a standard E B S attribute set. The set is made available as a drop down list to assist in defining the attributes of individual components (see Figure 28). The standard attributes defined in this manner can be grouped (e.g., Dimensions) in instances where such a grouping would be useful in navigating the attribute set. Mirroring the concept of consistency among attribute definitions, is consistency in the use o f units in defining quantitative attributes. However, unlike attributes, widely accepted standards for units are available. Functionality of encoding a list o f units is provided within K R I S (see Figure 29), from which an appropriate unit can be selected in defining attributes. A list o f standard linguistic terms that can be used in assigning values to linguistic variables can also be developed in a similar manner. I l l B Dimensions Length Width Height >••  Depth [Quantitative] []•[] ^Quantitative] [] [m] [Quantitative] [] [m] [Quantitative] [] [m] [Quantitative] [] [m] S-QualitativeCharacteristics ofOrganisms [Linguistic] [] [] <••  COSEWIC classification [Linguistic] [] [] {Reproducing/spawning period , 'r7!WiJ^S5^JNnyO| B- Organism Characteristics -Quantitative [Quantitative] [] [] L- Approximate population [Quantitative] [] [] Add at same level Add al sublevel Delete OK Edit Cancel At l i ih Name: |Migratory? Type:' IF] Class Unit Abbrevation • OK WSSBlffS Cancel Figure 27. Definition o f Standard Attributes 112 r'lemplateieMasterEnvironmentalfBreakdown Structure I- Path: ROOT PHYS ICALZOO LOGY. Mammals. I; Attribute Class j Standard Va Co Fl- Qualitative Characteristics of Organisms [Lnjjg] !•••• CO SEWIC classification [Lii Reproducing / spawning period jpl Migratory? [Boolear[^ < . jianuaiu value r jiai luaiu v aiuc L Add OK Cancel Figure 28. Use o f the Standard Set o f Attributes in Defining Component Properties riii[> A.. I Name a meter mm millimeter-; No Number of kg kilogram N NeWtOn •:: C Celsius Abbrevjhon j| Namex) p i -Type j OK j Cancel j i Type,; •Linear Linear Count Mass Weight / Force Temperature Add Figure 29. Definition o f a Standard Set of Units 113 4.3.6 Associations with Supplementary Information In modeling the environment in support of risk management, a distinction has been made between the information that is core to the process, and information that plays a supplementary role. A s an example, consider a research report on the migration pattern of Caribou. While the report may contain information that assists in determining the impacts o f migration on certain projects, modeling the information o f the report within K R I S is a less than ideal solution. The types of data fields required to support the information may only be applicable to a very few components, and also be an exercise in redundancy. A more viable solution is provided by allowing the referencing of information that is relevant to individual E B S components. In implementing K R I S , the associations with information sources such as documents, multimedia files, and websites have been modeled within a tab separate to the tab modeling the attributes. The separation o f the various types o f functions and information fields are designed to improve the clarity o f the interface. The 'Standard E B S Records' tab that models associations with information sources is shown in Figure 30. 114 Template:*Haster Environmental Breakdown Structure* Path: PiOOT.PHYSICALZO0 LO G Y Mammalc IJ-Code: . 02 J^D.escripti6^||Paper on migration variability .Type: Figure 30. Associating Information Sources with Environmental Components 115 In instances where the information is available as an electronic source (e.g., internet resource or image file), the individual entries can be directly linked to the information sources as shown in Figure 31. BBS Record Content Template: Master Environmental Breakdown Structure Path: ROOT.PHYSICAL.ZO0LOGY.Mamma(s. Record: 01 Caribou photo Cowent Name j Content File Name L G Ingres ® CA Academy ct Sci DATestRCON\lmages_mammal\Caribou.jpg View Add Delete Edit Close EBS Record Content File Name Template; Master Environmental Breakdown Structure Path: ROOT r^ YSI(^ L200L0GY.MarnmaJs. Record: 01 Caribou photo , -^ -^ -.,-..;„.-„,...— Name: jL G Ingles ©CA Academy of Sc| Scan File Nam: fD TestRCON\lmages_mammal\Caribou.jpg Browse OK Cancel ' Microsoft Office Picture Manager : EJe Edit View Elcture Iools (Jelp J . * Caribou.jpg Zoom: -<, -4. Figure 31. Linking of E B S Records to Content Available in Electronic Form 116 4.3.7 Associations Wi th Risk Issues Given that a model of the environment is developed as described above, the question becomes how can the relationship between the project context and the risks of a project be represented? The conceptual perspective taken in answering this research question is presented in Chapter 3, whereby the notions of risk drivers and gateways are introduced. In implementing these notions, the risk driver - risk issue relationship is modeled in K R I S through associations between components o f the environmental view and risk issue components o f the risk view that is described in the following chapter. A n environmental component can drive more than one risk issue, while a risk issue maybe driven by more than one environmental component as wel l as components from other project views. In the implementation of K R I S within the RepCon system, the associations are modeled within a 'Risk Issues' tab as shown in Figure 32. The user is given access to the standard risk view through the A d d / Modify command, allowing the selection o f issues driven by the environmental component. 117 •1 Attributes | StandardJBS'Rer^rV: Risk Issues ] Mcro ] m T emplateaM aster' E nvironmentaliB feakdowmS tructure ,, Path: ROOT.PHYSICALGEOLOGY • • • Code: SOIL ' ."•Description: Soil ,. Type: | r v i - { I.Associated Risk Issues.J. >' •• ' Path '• •*|t Description1* SRR:EXTERNA1iPRYSICALGE0C0GICALIGR0UNDC0NT1 Ground contamination < OK Car eel ugs • • ! B • a-L-J a-SRR Register Standard Risk Issue Registei • MANAGEMENT Category Management Risk • EXTERNAL Category External Risk g •POLITICAL. Subcategory Political Risk • ECONOMIC Subcategory Economic Risk H - • ' C U L T U R A L Subcategory Cultural AStakeholderRisks. ':. B • PHYSICAL Subcategoiy Physical Environmental Risk • -. . B • GEOLOGICAL Class Geological Risks •.?•.•: • LANDSLIDES Issue Landslides • SINKHOLE Issue Sinkhole ! B- 0 GROUNDCONT- Issue Giound contamination • •• 'i--Q :CONTAMSOIL Event.Contaminated soil encountered:: ; . - • CONTSEDIME Event Contaminated sediment encountered: EJ • HYDROLOGIC Class'Hydrological risks • • EJ • LANDUSE Class Land Use Risk . ; • • • ' • ; : • TECHNOLOGY Category Technological Risk B0CONSTRUCTN Subcategory Construction related risks:.' B-:B] DEWATERING Issue Dewatering risks . • 1+1 O F X Q A V A T i n N I S K I J R F x r - a v f l l i n n r i s k s _ _ > ^ 4 _ J •lYJi, OK Cancel , 1 Figure 32. Model ing the Risk Driver - Issue Relationship through Associations 118 A s discussed previously, in some instances the validity o f the driver - issue relationship is determined based on the properties or attributes o f environmental components and the values that the properties take on. In the 'Ground contamination' risk issue example, soil would be a driver of the risk issue i f contaminants present in the soil exceed certain thresholds. Knowledge regarding the criteria that should be satisfied in order for a risk issue to be driven by a particular component is modeled through sets of conditions defined in terms of the component attributes. For the example being considered, the condition that either the copper, lead, or zinc content in the soil should exceed certain concentrations is specified as shown in Figure 33. 1 8 Based on Contaminated Sites Regulations of B C standards (Province of British Columbia 2003) for toxicity to soil invertebrates and plants. 119 tf! Attributes"^ S J a r ^ J E B S R e c o t p j f i i s k Issues |"Memo ] ' ' j " . •If'Template: Master Environmental^ • " ';:- •> Path ROOT PHYSICALGEOLOGY Code: (SOIL _ _ [ ' • - Descrif^tcMjrr|Soir ' Associated Risk Issues Path Description lSRR :E^TiBNAL?BHY,SICA ! Ground contamination Add/Mod ly j Condition; j IOK-.'. . Cancel j» iv > : . Template Master Environmental Breakdown Structure-Path ROOT PHYSICAL GEOLOGY Risk Issue SRR EXTERNAL PHYSICAL GEOLOGICAL GROUNDCONT Conditions ' maRtu-ibutef tBIifCondiuonl WaGeM J Jn t Copper (Cu) content: OR Lead (Pb) content OR Zinc (Zn) content GT GT GT 150 -1000. 450: mcrg/g. mcrg/g mcrg/g Add ' 'Delete? Edit Clo*e Figure 33. Model ing Risk Issue Conditions 120 Individual conditions of the form attribute - logical condition - value are combined using A N D / O R in building up the condition for each risk issue. The dialog box used in the specification of each line is shown in Figure 34. K t g f e m ' V . -• . . ' . !KL? ' . . iiU . . . -.Template: Master Environmental Breakdown Structure '"V ' Path: ROOTiPHYSIGAIiGEOLOGY. . ; . / . ' . ' , : \ ' \ - • -Risk Issue: ,SRR:EXTERNAL PHYSICAL.GEQL0GICALGROUNDC0NT Relation:-, j AND If-I Attribute: Condition: Copper (Cu) content Units:'- mcrg/g Value 1. (l GT zl EQ Equal to. GE G reater than or equal to LT Less than LE Less than or equal to WRWithin range [Value 71 ..Value 2] :• . NR Not within ranqe [Value T, Value 2] mm •111 : " " 0 K ' f C a n c e l Figure 34. Specification o f Risk Issue Conditions 121 4.3.8 Memos In addition to attributes, associations with supplementary information and risk issues, a text data field has been implemented within RepCon for each environmental component. The ' M e m o ' text field is intended to serve as a repository o f miscellaneous notes such as those regarding the creation and update of components and short descriptions of the component. A n example of a memo field in use is given in Figure 35. •[8>3jTi3HfflIig A'ttnbutesj Standard| EBS .Records ||_Risk Issues1 Memo | .Te*mplate:;Master.Environmen(ai'BreaKaown:Srructure • .Path ROOT.PHYSICALHYPSOGRAPH . . " Code ' B25400000 1 \ Description , Rock outcrop Type: j£>ih-Memo mmm 1 Outcrop - A portion on the surface where one or more bedrock geological formations are exposed. Saniaya 1 June '05 I , i ii 1-1 OK I Cancel Figure 35. Example Use of the Memo Fie ld o f Environmental Components To summarize, K R I S provides the architecture for an organization to develop a S E L . The S E L is a library of environmental component definitions named and categorized according the preference of the organization. Attributes of importance to the risk management task can also be defined for each component. Risk issues likely to be driven by individual components can also be signified and conditions required to be satisfied in order for the issue to be relevant can be encoded. The ability to define a standard set o f attribute identifiers and unit identifiers is also incorporated. Definition of a S E L allows an 122 organization to retain a standard vocabulary that describes environmental components and their relation to risk issues. It is stressed that flexibility is provided for an organization to develop their own vocabulary. 4.4 Project Envi ronmenta l M o d e l A user can adopt one o f two approaches or a combination o f the two in building up the environmental model of an individual infrastructure project such as the O L B project that serves as a case study for the research. One of the approaches is to make use of templates or parts of templates (including individual components) of the S E L in developing the model. In order to illustrate the different aspects of the K R I S methodology let us assume that the O L B project is the first of many projects undertaken by a particular organization, and that a S E L does not currently exist. In the absence o f standard components, a user can define components on their own, i.e. define components from scratch, which is the second approach towards building an environmental model. The project model in hierarchical form is developed by initially defining a component at the environment level of the hierarchy, and defining other components at lower levels. In the implementation o f K R I S within RepCon, components can be defined as shown in Figure 36, in a format similar to the definition o f components on the standards side. 123 © F i l e Project_View T V n p | d i B _ V i e i y ! . ' Standards SSL EBS _ fflWW* - , K ' • ' .t=!U 1=^.1 .Window Help, . ' j b . 1 . 6 ! ] x . . . > 31 JE J> m E l IRi )EN«f5Enw Ready Add at same level Add at sublevel Copy standard component to same level Copy standard component to sublevel Delete Edit JJL-Jii 1 //, Values ||Standard EBS Record: j Rick Itsuus / Eventsj^rfroje'ct Records |(«Memcfl° Path: PRJENV. "i Code: Description:,] cliypewj Class. . •»• | Attribute .Description '' - . I Class' ' It B/Q7L I Unit: llTl Inherit attributeidefinitionfromrabove level Add " Delete Edit I '/, .QK ~ | . Cancel-. , :j, v i Figure 36. Addit ion of Components in Building up the Project Environmental Mode l 124 A component defined in this manner is initially devoid o f attributes, as well as associations with supplementary information and risk issues. They are required to be defined by the user in a manner similar to the definition of a new component on the standards side. However, unlike the standards side where the associations are made with components of the standard risk view in defining the driver-issue relationship, on the project side the associations are made with components of the Project Risk Register (described in the following chapter), that represents the risks o f the particular project being analysed. Conditions under which the relationship holds can also be defined in terms o f any attributes defined by the user for an environmental component. 4.5 Values of Component Attributes The attributes o f environmental components such as the estimated population o f a bird species, the concentration of a contaminant in soil, the expected long-term interest rate, and the average income o f facility users are different from one project to another, and in some cases even within different areas o f the same project. The average income of facility users in the O L B project example would be quite different from that encountered on a project in the developing world. In a somewhat similar vein, properties such as the era to which they belong, and their status in terms of having been studied / unexamined can take on different values for archaeological sites that are present within the project footprint of the O L B project, resulting in each site posing a unique set of risks. Thus, in assigning values that represent the conditions characteristic o f a particular project, distinctions also need to be made between different areas o f the project. The concept of gateways identified in the previous chapter is used for this purpose. Gateways are frames in space and time that are used in establishing the location of risk drivers, i.e. environmental and project components. The concept of gateways is modeled through spatial and temporal locations in the implementation of K R I S . A set o f locations that model the physical areas o f the project footprint and temporal divisions in the project timeline can be defined, and the environmental components mapped onto the locations to place them in space and time. The set o f locations that are common to all views o f the 125 project are modeled through the project physical view. The set of spatial locations adopted for the O L B project is shown in Figure 37. File Project_View T;emplafo_View Standards PCBS Window Help-1 - S\ PR Project Okanagan Floating Bridge &. Approachways EE1- SPATIALLOC Location Set Spatial Locations GPRJ Location Global Project !•••• WEST APR Location West End Approach ! WE5TINT Location West Side Interchange | LAKE Location Lake : !•- EASTAPR Location East End Approach i-- DRYDl Location Graving Dock Site - Bear Creek South j- DRYD2 Location Graving Dock Site - Kelowna City Park DRYD3 Location Graving Dock Site - Highway 97 Pullout (Rest j • DRYD4 Location Graving Dock Site - Penticton | EASTENDN Location East End of Bridge - North Side EA5TEND5 Location East End of Bridge - South Side |- WESTENDS Location West End of Bridge - South Side L WESTENDN Location West End of Bridge - North Side Area),t Ready •."""'."""•,-L' /A Figure 37. Definition of Locations for Okanagan Lake Bridge Project In defining the components of the project environmental model, values that are representative of the location at which the component is present are assigned to its attributes. For example, the bird species 'Western grebe' that is red-listed under the B C provincial species ranking system is present within the O L B project area. Values of attributes o f importance that include the ' B C provincial species ranking' and details as whether the species 'Breeds in the area?' can be assigned as shown in Figure 38. 126 PatkENV.PHYSICALZOOLOGY.BIRDS. Attribute: Breed in thearea? Value Type:,Boolean Location Range Location Range - Value WESTAPR-EASTAPR False Add Delete Edit OK Cancel, Path: ENV.PHYSICAL.ZOOLOGY.BIRDS. Attribute: Breedinthearea? Value Type: Boolean • Start Location: JEASTENC"V] Finish Location: Condition R.. Co... Value 1 EQ False Standard Condition (for viewing only) DRYD3 GravingDockSite- Highway 97Rullout(ResthieirM: DRYD4 Graving Dock Site - Penticton .. r :"~f EASTENDN East End of Bridge - North Side : EASTENDS East End of Bridge - South Side :| J WESTENDS West End of Btidqe • South Side __ is W E S T E N D H West End of Bridji- - N r r h ': de Add Delete Edit i R . Co.. Standatd Value 1 Standard Value 2 Project Recordsj Code _D escript iqrj^ . < > Add OK Cancel Figure 38. Assigning Attribute Values to Components Present at Different Locations 127 A global project location (see Figure 37) is used in assigning values that are invariant throughout the project. 4.5.1 Associations with Project Information Similar to supplementary information that is general in nature, i.e. not specific to an individual project, which can be associated with environmental components in the form of standard environmental records, information that relates to an environmental component and is specific to the project might also be available as documents, multimedia files, etc. Associations between environmental components and such information is allowed to be created through a 'Project Records' tab. The process of creating the association is shown in Figure 39. It is noted that the functionality for developing a grouped list o f project records as shown in the bottom half o f the figure was a pre-existing structure within RepCon and was used in developing K R I S . The structure allows users to add references to project records under the various groups. 128 (iAHnbUes LValuesj;ltandj|id EBS Recorjsj, Rb^ igues / |yenjs j Piopct Records j Memo_) Code' JPRJENV j ' 'Description:}) OLB Project Environment |j Type .[£<-, . r « w j y ^ J h j | , ; ,Y >; ': Project Records . . f o w ' -', ' " ' • •> Code' "l?;Desctiption '••'4, Date iPH-A001 PH-A002 Aerial photo • Site Aerial photo • Night traffic 08JUL03 08JUL03 View ) F Remairk , [ Add/Deiete OK i Cancel B • B • PH Photos @ A001 .Aerial photo - Site: @ A002 Aerial photo • Night traffic • VC Video clips ••• ["J LT Letters/memos to : • LF Letters/memos from • P/C Permits/certificates: ~. • CM in Consultant meeting minutes :• . |~T| SMin Site coordination meeting minutes Q TMin Trade meeting minutes f£] OHSMOccupational Health & Safety meeting minutes • Mmin Miscellaneous meeting minutes \7\ CDwg Construction Drawings/Details . SDwg Shop Drawings • Schd Schedules/work plans | | A1 Preliminary schedule ! []}D12 Detailed - Drydock works ' Q RR Requests for.information .. ITl *-»I Site instrunhnns._. . _ _ . _ — OK Cancel: Figure 39. Associating Project Records with Environmental Components 129 The process of defining environmental components, defining attributes and their values at different locations, associating the components with supplementary information and project records, and signifying the risk issues driven by the components results in a definition of the environment o f an infrastructure project. A partial view of the model developed for the O L B project is shown in Figure 40. A facility for generating reports of the components and their characteristics is provided within RepCon. The report generated for the O L B project that provides a complete list o f the components and their attributes is provided in Appendix A of the thesis, while screen captures that show the complete set of components is provided in Chapter 6. 130 • • • • • • fe j * ! * File Project_View iJem^tg^Weja^' Standards ' EBS'- Window Help * '* ' \® x j t a l i • PRJENV Environment OLB Project Environment PHYSICAL Class Physical Environment EI-DE5AREA Sub-class Designated area AA10550000 Entity farm AD01000000 Entity Archeological Areas B- ROADRAIL Sub-class Roads and railways : DA25000000 Entity Road (Gravel Undivided) B - DA25050000 Entity Road (Payed Divided) DA25050120 Sub-entity Road (Paved Divided) - Elevated -1 lane each way DA25050130 Sub-entity Road (Payed Divided) - Elevated - 2 lanes each way DA25050150 Sub-entity Road (Paved Divided) •- Elevated - 4 lanes each way DA25100000 Entity Road (Paved Undivided) B HYDROGRAPH Sub-class Hydrography GA24850000 Entity Stream / River GB15300000 Entity Lake El-BOTANY Sub-class Botanical components • •ZOOLOGY Sub-class Zoological components m BIRDS Entity Birds E!-Mammals Entity Mammals ! - AMPHIBIANS Entity Amphibians j REPTILES Entity Reptiles L FISH Entity Fish B SOCIAL Class Social environment ABOROGINAL Sub-class First nations communities COMMUNITY Sub-class Local community 1+1-ECONOMIC Class Economic/Financial environment B POLITICAL Class Political environment ED REGULATORY Class/Regulatory environment Ready mm Figure 40. Partial Overview of the Okanagan Lake Bridge Project Environmental Mode l 131 The use of this model in risk management is described in the following chapter. Bui lding up an environmental model from scratch in this manner for each project that an organization undertakes would be an onerous task. The information and knowledge utilized on the O L B project, such as the attributes of importance of individual components, the risk issues driven by individual components, and the conditions under which the driver-issue relationship is valid, has the potential to assist in this task, in instances where similar types of components exist on future projects. The first step towards the re-use of the components is their addition to the S E L . While not implemented currently, the facility w i l l be provided for saving the complete set of environmental components as a template, a subset of the components as a template, or individual components to the standard side. Currently, this task has to be carried out by manually defining components on the standards side. In all instances, the components are first added to a M E B S template, extracts from which are used in creating templates corresponding to individual environments. A s described previously, the S E L contains definitions o f environmental components in a format that is project-neutral. Thus, in transforming components to the standards side, they are stripped o f their values and project records as such information is highly project specific. A l l other content is left intact, allowing their re-use on future projects, such as the Sea to Sky highway project that is assumed to be undertaken subsequent to the bridge project, and serves as the second case study. Bui lding up the project environment model o f the Sea to Sky project can be expedited with the use of the standard components developed during the course o f the O L B project. While the projects themselves might be fairly distinct as a whole, they share several components o f a similar nature such as streams, a large number of political and economic components as a result of their existence within the same province, and components such as archaeological sites. In building up the project environmental model, a user can copy over standard descriptions of such components as shown in Figure 41. While actual attribute values would be different, the task o f creating the model is lessened a great deal by the presence of content such as attributes of importance. Additionally, content regarding the driver-issue relationships is also present, facilitating the identification of relevant risk issues, a process described in detail in Chapter 5, which describes the risk view o f K R I S . A partial 132 model of the environment o f the Sea to Sky highway project developed utilizing content identified and archived in analyzing the O L B project is shown in Chapter 6. f • F|le Project_View T.cTin'ate, 'iew. Standards EBS Window Help _ 51 x\ 3 Si \& i© jlto' ft- £ El-Add at same level Add at sublevel Copy standard component to same level Delete Edit Copy standard EBS B-ROOT Environment BC Interior-Lacustrine Environment B PHYSICAL Class Physical environment i a-GEOLOGY Sub-class Geology CLIMATOLOG Sub-class Climate El- DESAREA Sub-class Designated area •i: • El- BUILDING Sub-class Building . (+] STRUCTURE Sub-class Structures . ffl ROAD RAIL Sub-class Roads and railways ..! 3 UTILITY Sub-class Utilities ; • • HYDROGRAPH Sub-class .Hydrography GA24850000 Entity. Stream' IR ivet RRi:Rinnnnn."Fntihi i OK • Cancel Figure 41. Use of Standard Components in Defining Environmental Mode l of the Sea to Sky Highway Project 133 4.6 The Significance of the Physical, Process, and Organizational Domains in Project Risk Management A n infrastructure project is necessarily made up o f an ensemble of physical components, which in turn consist of even smaller components, and finally o f materials such as steel, concrete, and plastic. In developing KRIS, physical components are defined as the elements and materials that make up the temporary and permanent structures of the infrastructure project. Whilst the construction materials and components used in a project continue to undergo continuous scrutiny aimed at identifying their properties, epistemic uncertainty can still persist regarding the behaviour of both materials and components. Additionally, natural variability in performance can also introduce uncertainty into the physical component ensemble o f an infrastructure project. These uncertainties in turn can translate into risk events ranging from the catastrophic failure o f components or the structure as a whole, to deviations in the scope and quality required. A process component is defined as an element of work performed during the course o f a project (Project Management Institute 2000) and requires the use o f human and / or material resources. Process components can act as risk drivers due to uncertainty associated with the scope of the component, unexpected results associated with the process, or due to characteristics of the resources used by the activity. For example, the extent of the excavation activity could be uncertain at the start of a project, while it may also result in unexpected events such as damage to adjacent properties. This is in addition to uncertainty brought on by the performance o f the equipment and crew used for the process. In some instances, process components may drive risks due to characteristics o f the resources used (e.g., size o f the resource). Infrastructure projects typically bring together a large number of organizations, which in some instances are unknown to or unfamiliar with each other. In modeling the project context in support of K R I S , the organizational / contractual view is defined as the organizations and individuals involved with the project and the contractual relationships that exist among the organizations and individuals. Interface issues arising out of a lack o f trust, the inexperience o f project parties, and their financial instability give rise to risks such as legal battles and the bankruptcy o f joint venture partners. 134 4.7 Current Approaches Towards Representing the Physical, Process, and Organizational Domains A fairly large number of representation paradigms are currently used in modeling the physical, process, and organizational aspects of a project, only a few of which are described in this section. Two-dimensional or three-dimensional Computer Aided Design ( C A D ) models are used in representing the physical structure of a infrastructure project. A listing of project components may also be developed using a classification scheme such as Uniformat II or Uniclass. Uniformat II is a classification format that originated in the United States, and is used in building works and related site works. Primarily used in ensuring the consistency among the project representations adopted in the economic evaluation o f building projects (Charette and Marshall 1999), Uniformat II consists of elements organized into three hierarchical levels. Level 1, the largest element grouping consists o f Major Group Elements such as substructure, shell, and services. Group Elements make up Level 2 and include foundations and basement construction under the substructure Major Group Element. Basement construction consists o f two individual Elements (Level 3): basement excavation and basement walls. It is noted that while Uniformat II takes a product-centred approach it contains some elements that could be construed as processes, such as site clearing. Uniclass is a construction information classification system developed by the National Bui ld ing Specification Services o f the U K , and is structured as a faceted classification scheme. Fifteen facets are employed in Uniclass, including F (Spaces), H (Elements for c iv i l engineering works), and K (Work sections for c iv i l engineering works). A hierarchical system is used within facets in classifying items in detail (Kang and Paulson 2000). For example, contained within H lies elements such as H3 (Embankments, retaining walls, etc.), that consists of H311 (site clearance), H312 (ground contouring), and H313 (stabilisation). A network model of project activities is a popular representation of the processes o f a project. The underlying network can also be represented graphically as a bar chart or linear planning chart, and is generally used for scheduling and planning. JJDEFO is another method used in process modelling, and describes the information and product flows between various activities. A Work Breakdown Structure (WBS) is a deliverable-135 oriented grouping of project components (Project Management Institute 2000). A W B S is organized into several levels with each descending level representing an increasingly detailed description of project deliverables, with individual work packages forming the lowest level. 4.8 Representing the Physical, Process, and Organizational Dimensions in Support of KRIS A s introduced previously, the physical, process, and organizational / contractual views used in the K R I S methodology make use of data structures developed and implemented previously within a research system termed RepCon (Russell and Udaipurwala 2001, Russell and Chevallier 1997). These representations have been developed primarily in support of planning and scheduling and the selection o f construction methods. RepCon in its current state is programmed in C++ and makes use of the Pervasive relational database for data storage. In considering the existing models of the physical, process, and organizational / contractual views (herein referred to as the 'three views' for purpose of brevity) within RepCon, they contained a number of properties and functionalities that are useful for risk management as wel l as a number of properties and functionalities unnecessary for risk management. The models of these three views are also based on a hierarchical paradigm similar to the environmental view, albeit a shallow one for the organizational / contractual view. For each o f the three views, the facility for modeling associations with risk issues was added. A s aforementioned, the use of existing representations has allowed proof o f concept o f K R I S to be carried out while bounding the implementation effort required. However, the models o f the three views differ among themselves and with the environmental view in terms o f their interface and some functionality. Suggestions for improvements are identified in Section 6.3. The three views are briefly introduced in the following sections, along with references to publications by the developers o f the three views that provide further details. 136 It is also noted that in modeling the O L B project as a case study, models of the physical, process, and organizational / contractual view were developed alongside a model of the environment view. Details of the models of the three views developed in characterizing the Okanagan Lake Bridge project are presented in Chapter 6. 4.8.1 The Physical V i e w The physical view o f the project is accommodated by a structure termed the Physical Component Breakdown Structure (PCBS) that consists of a nine-level hierarchy (Russell and Chevallier 1998). The levels correspond to project, subproject, system, subsystem, element, sub-element, sub-sub-element, content, and material. A l l of the foregoing components can be described by user-defined attributes. In defining a project P C B S the user defines components at different levels in the hierarchy as wel l as attributes that describe the components. Templates that contain the set o f components that typically constitute a project o f a certain type can be created within the standards side of the physical view. Extracts from a single template or multiple templates can be used in defining the physical components o f a project. 4.8.2 The Process V i e w The process view (Udaipurwala and Russell 2002) is modeled as a hierarchical list o f activities. Templates o f activities that pertain to a certain project type or procurement mode can be stored on the standards side of the system. In addition to activities, project phases such as the design phase and the construction phase can also be defined through the process view. Whi le templates can be created, combining o f components from multiple templates in developing the process profile of a project is not facilitated, with re-use o f components being limited to components contained within a single template. 4.8.3 The Organizational V i e w The standard side of the organizational/contractual view consists of different categories of project participants such as architects, trades, suppliers, and insurers / surety (Arsalan 137 2004). Within each category individual organizations that belong to the category are listed. In defining the organizational/contractual structure of a project the user can select individual entries or the category as a whole and move it to the project side, and thereafter assign values to the defined attributes for each entry. The organizational view does not allow user definition of attributes, nor does it allow the creation o f templates that depict say the typical set of organizations involved in a project procured using a traditional design-bid-build approach or a F D B O M approach. One additional issue that needs to be considered is the justification for using a hierarchical paradigm for modeling the 3 views. The rationale for the selection of a hierarchical paradigm in the case o f the environmental view has been documented previously in the chapter. The arguments presented in the case o f the environmental view, such as the flexibility required to allow modeling at different levels o f detail and the ability to make use of inheritance in ensuring consistency also stand true in the case of the other three views being described. Furthermore, while not all modeling paradigms currently used for representing the physical, process, and organizational / contractual dimensions o f a project are based on a hierarchical structure, a significant number of them such as listings of components based on a Uniformat II classification are in fact based on a hierarchical paradigm, unsurprising given the fact that construction management information is inherently hierarchical in nature (Rankin 2000). 138 5 The Risk View The approach taken towards representing the risks of an individual infrastructure project as wel l as within an organizational corpus is the theme o f discussion in this chapter. The theme primarily relates to research question 2 that addresses modeling the set o f risks that pertain to an infrastructure project, and research question 5 that addresses information and knowledge re-use. Being the climactic chapter in terms of describing details of the K R I S methodology, the discussion also transcends into answering elements o f other research questions not dealt with previously. These include issues related to the exploitation o f the risk and project context models in order to gain insights that can assist in the decision making process and further treatment o f the project context-risk relationship. A description o f the project side o f the risk view modeled as a Project Risk Register begins the discussion. 5.1 Project Risk Register To recap, research question 2 is: H o w can the set of risks that pertain to an infrastructure project be represented? H o w can issues such as the absence o f standards in risk categorization and the need to provide ease of navigation among a large set of risks be factored into the model? What are the properties of individual risks that are important in carrying out the various tasks o f risk management and how can such properties be modeled? A s discussed previously, risk categorization offers advantages such as focusing attention on similar types o f risks that are l ikely to have a bearing on a project in unison and allowing comparable mitigation strategies to be developed for a set of risks that share common characteristics (Al-Bahar and Crandall 1990). Whi le most authors agree on its usefulness, the literature on risk management rarely agrees on the categorization strategy that should be adopted. A cross section o f the risk categorization schemes suggested in the literature is presented in Appendix C. 139 In executing risk management, an organization may use one of the schema suggested in the literature or devise its own categorization approach that relates to its thinking and terminology. Thus, in attempting to address the element of research question 2 that deals with the lack of standards in categorization, one is drawn towards the question of the role of the user versus the role of the computer (i.e., research question 1). Should flexibility be provided for the user to define and develop a schema of their choice, i.e., should it be the role o f the user to define a categorization schema or should the role lie with the computer-based methodology 1 9? The latter option necessarily involves constraining the user to a hard-coded schema or alternatively to a schema that allows limited editing and offers some advantages, specifically the ease of ensuring consistency and also offering the opportunity o f tailoring interfaces to suit the properties of individual risk components. These weigh against issues of practicality which dictate that the set o f categories would necessarily need to be augmented / amended as an organization gains continuous exposure to projects and the lack of a clear-cut "one fits a l l " categorization scheme that could be acceptable to many i f not al l organizations. Thus, in developing K R I S the role of the computer has been delineated to facilitating the creation o f a risk categorization schema and its population with risk issues and events by the user. It is noted that the role of the user i n this instance does not reflect a burden additional to the role o f a user populating a paper, spreadsheet, or database-based register that reflects the state of the art. In fact, as w i l l be explained as the chapter progresses, the burden on the user becomes progressively lesser as an organization accumulates risk content over a period o f time. Mirroring the observation made regarding characterizations of the environment, it is noted that the degree o f coarseness among the risk categorizations that have been suggested in the literature varies among different approaches. The P M I Risk Management Specific Interest Group (2002) utilizes a taxonomy consisting o f three levels. For example, it employs a Management category, sub-divided into Corporate, and Customer / stakeholder management sub-groups. Risk areas such as Organizational stability and Financial are listed under the Corporate sub-group. Other authors (e.g., (Al-Bahar and Crandall 1990) have adopted a two-level approach with risk issues being directly listed Herein, simply referred to as "computer". 140 under several risk categories. In considering existing computer-based approaches, many (e.g., Integrated Computer Engineering Inc. 2002; Kangari and Boyer 1987; Leung et al. 1998; Tah and Carr 2001) are based on fixed, pre-defined sets of categories, whereas others (e.g., Andersen and Madsen 2001; Patterson and Neailey 2002) do not accommodate risk categorization. A s described in Chapter 3, the concept adopted in K R I S is to organize risk components in a hierarchy, with a frame that describes the properties of components being attached to each component. Keeping in line with the decision made as to the role of the computer, the hierarchical structure provides the architecture for the user to define and develop a categorization of their choice. In developing a structure that facilitates the use of any one or a combination of the risk categorization schemas suggested in the literature, a hierarchy that consists of six levels has been adopted. O f these six levels, two levels serve to model risk issues and events, another serves as the root node of the hierarchy, while the additional three levels serve the categorization function. It is noted that the three levels provide sufficient capability to model commonly used categorization schema and the addition o f further levels has been discounted as it could accentuate problems associated with deep hierarchies, some o f which were highlighted in Chapter 3. The components at the various levels in the hierarchy reflect 'a part o f relationship, except the interface between the issue and event levels, which represents a 'results i n ' relationship. The different levels o f the hierarchy are as follows: Register: The register level serves as the root node of the hierarchy. It provides an umbrella under which all categories o f risk issues and risk events, as wel l as the issues and events themselves can be defined and described. Category, Sub-category, Class: The category, sub-category, and class levels are used in categorizing risk issues and events. The use of each of the category, sub-category, and class levels are optional, with the user being able to list risk issues under any o f the three levels, or directly under the register level, depending upon the categorization preferences of the organization. In populating the hierarchy for the purpose o f the case studies, three main categories: Management and Organizational 141 risks, External risks, and Technological and Execution risks have been adopted, an approach somewhat similar to that taken in the Universal Risk initiative o f the (PMI Risk Management Specific Interest Group 2002). Each o f the categories is made up of several sub-categories, for example the External risk category is made up of the Political, Cultural, Physical, Economic, and Regulatory risk sub-categories with Geological, Hydrological, and Land use risks being among the classes listed under the Physical sub-category. The particular categorization scheme has been chosen purely for illustrative purposes and the capability o f modeling any other schema is re-emphasized. Issue: The level o f the hierarchy that is used in modeling risk issues. Event : The level o f the hierarchy that is used in modeling risk events. In K R I S , the categories, the risk issues and events, and the properties of the components that relate to an individual infrastructure project are modeled on the project side o f the risk view making use o f the hierarchical structure described above. The specific structure adopted for this purpose is termed as the Project Risk Register (PRR) and a discussion on the development of a P R R incorporating a categorized listing o f risk issues and events follows. 5.1.1 Development o f the Proj ect Risk Register A s described in the section on risk workshops in Chapter 3, the team of workshop participants initiates risk identification by discussing the primary categories or areas o f risks, any sub-categories that may fall under them, and then by discussing risk issues and events that fall under each of the categories / sub-categories. In developing such a model within K R I S , the user would first build up the categorization structure by adding components to the hierarchy starting with a register node and then by adding components at lower levels. In the implementation of K R I S within the RepCon system the user can 142 add components by either selecting the ' A d d at same level ' or ' A d d at sublevel' commands, as shown in Figure 42. ism j0| File Project_View Te[Qgjaie^ig 'ffl) ' 'Standards , Risk Window^ Help* LLJi=Ji B ' | R E G Register ProjectRisk Register - OLB Project i ' | MGTORG Category Management / Organizational Risks El B EXTERNAL Category External Risks • JTECHOP Category Technological / Operational Risks S I DESIGN Subcategory Design Risks • J CONSTRUCTS Subcategory Construction-related Risks El-1 TRAFFIC Issue Traffic management issues Ready El-El-a-E5CAVATION Issue Excavation risks | WORK WATER Class Crew working over water _ _J EXI5T5TRUC Class Refuse of existing structures H J DISPOSEEX Class Disposal of existing structures El -1 TRANSPORT Class: Risks of Transporting Construction lj | STORAGE Class Storage of Materials El- B OPERATION Subcategory Operational Risks Add at same level Add at sublevel Set as Active Set as Inactive Delete Edit Figure 42. Addit ion o f Components in Bui lding up the Project Risk Register The interface of the P R R allows the hierarchy to be expanded or collapsed. A s shown in Figure 42, a short description is displayed next to the identifier of each component along with text that signifies the level at which a component is placed (register, sub-category, issue and so forth). The 'Delete' command allows components to be removed from the hierarchy subject to the condition that it has no children that require prior deletion. The 'Edi t ' command provides access to the frame that models the properties of the 143 components in the hierarchy and is described in detail in the following section. The interface chosen that affords users the ability o f viewing the risk hierarchy and the properties of components separately offers several advantages. The ability to view the risk hierarchy as a whole while expanding or collapsing parts of the tree to focus on segments allows workshop participants to gain a global/localised view of the profile of risk issues and events of the project and also allows them to easily navigate within the set o f risk components. For example, i f the users wish to examine 'Land lease issues' in the midst o f examining 'Dewatering issues' to assess the possible consequences of property settlement during dewatering, they can simply expand the Management / Organization risk category and then expand the Contractual subcategory and so forth to navigate to 'Land lease issues'. However, it is noted that the efficiency with regards to locating a component of interest within a hierarchy lies with the logic incorporated into the categorization scheme that is adopted. Most categorization schemas are based on such logic even though the rationale used for categorization is different between the approaches. In considering other state o f the art approaches, registers based on databases such as Risk Radar (Integrated Computer Engineering Inc. 2002) while allowing the user to move between forms that present the properties o f risks, do not provide functionality for viewing the complete set of entries in a categorized fashion. Thus, the explicit support for risk categorization, not simply in terms of allowing a risk to be assigned to a category, but in allowing such categories to be visualized and navigated can be considered as a useful contribution of K R I S especially in view of the espousal o f risk categorization by a majority o f the literature. The issue that arises next in answering research question 2 relates to the properties of risk components, i.e. what are the properties o f individual risks that are important in carrying out the various tasks o f risk management and how can such properties be modeled? In answering this question, acknowledgement is made o f the significant efforts by several authors, (e.g., Department o f Premier and Cabinet - Tasmania 2004; Ward 1999; Wil l iams 1994), who have dealt with the issue of the properties of risks that should be modeled within a risk register. Such properties have also been modeled within computer-based approaches (Andersen and Madsen 2001; Integrated Computer 144. Engineering Inc. 2002; Patterson and Neailey 2002; Tah and Carr 2001). A l l of these approaches make use of the Microsoft Access relational database for data storage and present the input fields within a series of forms. A portion of the list o f properties modeled within K R I S has been gleaned from an extensive review o f the literature assisted by discussions with people experienced in conducting risk analyses on infrastructure projects. Several additional properties are also modeled within K R I S and relate to modeling the project context-risk relationship, properties that are absent in current approaches primarily due to the non-treatment of the relationship within such approaches. It is also noted that in addition to modeling properties of significance, K R I S facilitates the development and use o f a standardized vocabulary o f values that these properties can take on and which can be used in characterizing individual risk components. In combination with the support provided for developing an organizational standard for classifying and managing risks, this moves an organization towards acquiring a standard vocabulary that describes risks. A s aforementioned in Chapter 3, current approaches provide very limited support in this regard. A s introduced previously, the properties o f risk components are modeled within a frame attached to each component o f the risk hierarchy, and which in the K R I S implementation can be accessed through the 'Edi t ' command (see Figure 42). Each frame consists o f several tabs (similar to the tabs o f the environmental view components) that group properties o f a similar nature together. It is noted that some properties have been associated with only risk issue and event components of the hierarchy, as components o f the other levels o f the hierarchy are primarily used in aiding risk categorization. Additionally, some properties are pertinent only to risk events, such as the performance measures affected by the event, and are only modeled at the event level of the hierarchy. The narration o f the properties is organized along the lines o f the different tabs o f the frames and is as follows. 5.1.2 Description Each component of the risk hierarchy is assigned a 'Code ' which in combination with the 'Path' o f the component along the hierarchy serves as the unique identifier o f the P R R 145 component (see Figure 43). A 'Description' field allows the input of the short description that appears alongside the 'Code ' in the P R R hierarchy. Lengthy descriptions within the hierarchy itself can distort its clarity creating a need for the length of the 'Description' field to be restricted. Therefore, an 'Extended Description' field that can be viewed only while editing the properties o f individual components is used to model a more detailed description o f the risk. The 'Type ' field denotes the component type, i.e., register, category, sub-category, class, issue, and event is automatically populated during the creation of the P R R hierarchy. jf Description [Risk Dtivets ^ Measures Affected jj Values |i Mitigation j Standa^jllH R e C Q r j f J - ft-ggc'. R.g99^JLJlgg!S. 1—4 Path- REG.TECHOP.OPERATION.ACCIDENTS TRAFFIC ' ! Code. jSMMHUlHs. Description: j Accident involving hazardous material transport far-i; Type. Event. ji-Extended Desctiption Accidents involving trucks carrying gasoline, solvents, pesticide etc. li l Influence - Local /.Global ' , • f - , Applicable Proiect Phase ; iLocal H i ' 0 peiation OK Cancel Figure 43. Descriptive Properties o f Risk Components A risk event, issue, or even a category of risk issues can relate to a project as a whole (e.g., inflation that impacts all aspects of the project, i.e., it has a global influence), or it can be local in terms o f its immediate influence on the project (e.g., a slope failure that occurs at a specific location). The distinction between local and global assists in 146 determining how best to incorporate related risk events into an overall project model for purposes of predicting performance. For example, uncertainty associated with inflation is best treated through the overall economic model of the project, while for the slope failure example, it would be treated at the work package level. The 'Influence - Local / Global ' field allows the specification of the sphere of influence of risk components by selecting either ' L o c a l ' or 'G loba l ' from a dropdown list. A value of ' N / A ' (Not Applicable) can be selected in instances where such a distinction cannot be made, particularly for components at a higher level in the hierarchy. In addition to a local or global sphere o f influence, the influence o f P R R components can also be described in terms o f the project phases that they are most l ikely to impact upon. Infrastructure projects are typically made up of several phases such as feasibility, design, construction, operation, and in some cases a dismantling phase. The risk issues that are relevant to the project would vary between these phases, and even in cases where similar risk issues are present during several stages, the risk events are l ikely to be very different and are also l ikely to be managed separately. A n example would be the risk issue "inclement weather", which would give rise to risk events such as "loss of productivity of work crews" during the construction phase, whereas "poor revenues due to lower usage rates" is a l ikely event during the operation phase o f a tolled highway project. The specification o f the phase is carried out through an 'Applicable Project Phase' field, which has been implemented as a dropdown list containing a list o f project phases. A n issue which warrants mention at this juncture is that o f consistency within the different project views. A s described in the previous chapter, the phases of the project being modeled are defined through the process view of RepCon (see Figure 44). Thus, in populating the 'Applicable Project Phase' field, the populace o f the dropdown list is drawn from the process view o f the project, as opposed to being user-defined within the risk view or hard-coded. More specifically, the risk components are associated with the phases defined in the process view. This ensures that a consistent set of identifiers is used throughout, and is a strategy that has been adopted in other similar instances where the same set of project information is used in two or more separate views. 147 El-Pre-Feasibility Feasibility Design Construction Operation Major Maintenance Dismantling Add phase Add subphase Copy standard phase Copy standard subphase Delete Edit |Setup phase. 1 , ** ' " j — Figure 44. Development of a List o f Project Phases 5.1.3 Risk Drivers The relationship between risk drivers and risk issues / events introduced in Chapter 3 can be summarized as follows. A project context component on its own or in combination with one or more other components drive a risk issue, which can result in a risk event, the nature o f which can depend upon the particular combination of drivers that drive the risk issue. It is noted that the combination of drivers can be a function of the spatial and temporal location that is being considered. The modeling o f the driver-issue relation through the project context views was discussed in the previous chapter. The current section takes that discussion further, starting off with the driver-issue relationship for the case o f risk issue components. 148 The 'Risk Drivers ' tab of a risk issue component is shown in Figure 45, and displays components from each o f the environmental, physical, process, and organizational views. The entries that appear are components that have been signified as driving the particular risk issue through the risk issues tab o f such components as described in the previous chapter. The relationship can also be modified from the project risk view using the 'Edi t ' button located next to the window of each view. The 'Edi t ' button gives access to each o f the 4 project context views and allows components to be identified as driving the risk issue. The environmental view is taken as an example and shown in Figure 46. •Code I N A R C H A E O . Description Fr t nations archaeologcal zisi . a^^ gfc *wO*j' *>fS&r- * VWtW" ^bVcriphorCjRjsk Drivers"-! S'andard Rrl Reccrds j.Proiect Records ] Memo j Path REG EXTERNAL PHYSICAL LANDUSE 'Type Risk Drivers Irom Environmental View Risk Driers Irom Physical View rBath n • Description E N V P H Y S I C A U D E S A R E A AD010" Archaeological Area Path De<cnption_ Edit Edit -H,' ;T*r> •* A * - ' r . **-w r i T * ? s :^f?L- 7 \ $ ? A . ~ „-^«v ...Risk-Drivers from Process View •33>&-s '<.e*>t Path Description (027.01 • 028.01 < Excavate dock basin Clear West Side Road Area • •"'&'R'"k Drivers'from Organizational View ~ fpT Role ' """ 1_ " ' < I B M P 1 OK I Cancel Figure 45. Risk Drivers Folder o f Project Risk Issue Components 149 • f j ENV OLB Project Environment B • PHYSICAL Physical Environment E • GEOLOGY Geology H • SEISMICITY Seismic Activity a • CLIMATOLOG Climate Ei • DESAREA Designated area U 0 AD 01000000 Archeological Area L Q A L 2 0 1 5 0 1 3 0 Park - Municipal i- Q R O A D R A I L Roads and Railways r • DA25100000 Road - Highway 97 i • DD03250140 Bridge - Floating - Existing Bridge El TJ HYDROGRAPH Hydrography El TJfJ BOTANY Botanical Components B D ZOOLOGY Zoological Components H Q BIRDS Birds, EJ • MAMMALS Mammals Fl • AMPHIBIANS Amphibians © • R E P T I L E S Reptiles i+i n FISH Fish OK Cancel Figure 46. Interface for Selection of Drivers from the Project Environmental V i e w The modeling o f the driver-issue relationship becomes more complicated when the modeling of the impact o f drivers on risk events that result from the risk issues is considered. A s mentioned previously, risk events as well as their consequences are a function of the set o f drivers that are associated with a risk issue at a particular location. For example, consider the scenario shown in Figure 45. In this scenario, both the 'Excavate dock basin' activity for construction o f the graving dock, and the 'Clear west side road area' activity in support of the construction o f the west side approach roadway are activities that disturb the existing terrain and are l ikely to drive risk issues such as 'Archaeological remains encountered' and 'Paleontological remains encountered'. Similarly, an 'Archaeological area' is also a driver o f the risk issue 'Archaeological remains encountered'. However, the 'Archaeological area' component o f the environmental view only occurs at the site of the graving dock operations and not at the site of the west side approach road. Thus, while there is a significant possibility o f an 'Archaeological remains encountered' event at the graving dock facility, the possibility o f 150 such an event is comparatively less significant at the site of the west side approach road. Thus, in defining the risk events that result from a risk issue, one first needs to identify the locations at which the drivers are present, and within K R I S a 'Location' field is used in the 'Risk Drivers' tab o f risk event components in modeling such a property. The 'Location' field of a risk event (see Figure 47) lists out all the locations at which the drivers of the parent risk issue are present, and is automatically generated by the computer system. The driver windows for each of the 4 views reflect the location selected by the user, i.e., only the drivers that are present at that location selected are displayed. In the current example, when the user selects the graving dock site (see Figure 47-A) both the 'Archaeological area' and 'Excavate dock basin' are displayed. However, when the site of the west side approach is selected, only the 'Clear west side road are' is displayed as a driver (see Figure 47-B). Thus, the user can examine each of the locations and observe the particular combination o f drivers present at each location. Thereafter, i f a location is deemed to have a combination of drivers that warrant the consideration of the risk event, the user can continue adding other information such as probability and consequence values. 151 'MescrVtonl, Bisk Drivers' |7Measures" Affected ]}Values)' Mitigation |jiandard Risk Record^fProiect RecordsfMemo ' l , Path: REG.EXTERNAL.RHYSICAL.LANDUSE FNARCHAEO. jCode- JCHREMAIN Description: "(Archaeological remains encountered \ ' Location' Type | £ f j ' ' „ . , Risk Drivers from Environmental View : . ' " " t •' Risk-Driver. Path- It-Description •Path jDRYDI jfj WE ST APR West-End Approach jEjy.PHYSIO^r:pESAREA.AD010".".] Archaeological Area [ i Remove | '."Apply Condition I " "Risk Drivers frbm'Process View ."Risk Drivers from Organizational View Path Description R.. ! Role [027:01* Excavate dock basin i (A) i rai ISJIL_ r _ J J ) - -M OK Cancel jiw/L. ?: J"._ - • — Description Ri-kDri%eis j Mea-ures Affected j Values | Mitigation] Standard Risk Records ! Proiect Record: j Memo) ^Type: ' |Evenf^_» SRJ|' ; '• T'^. . * \ "' Location: ESTAPR jfj Path._R E G :EXT E R N AL PH YSI CAL. LAN D U SE. FN AR CHAE 0 .'• Cdde:;jCHREMAIN Description-^ JArchaeological remains encountered RiskDnversfromEnvironmental v*iew Path ' Description '•' P'SkP"~|DRYD1 Graving Dock Site - Bear Creek South I Path ; {..uusjuiiprroF ==>= m Remove Apply Condition Risk Drivers from Process View Risk Drivers from Organizational View Path . . . I Description •Oiagrj Clear West Side Road Area > R.. Ii Role , > (B) > OK. • f Cancel Figure 47. Model ing o f Risk Driver Information for Project Risk Events 152 It is noted that in the current implementation, grouping according to locations is supported only for spatial locations. It is anticipated that the functionality for grouping drivers according to temporal locations, as wel l as the ability to group drivers based on a particular spatial-temporal combination (e.g., West end approach in Spring 2006) would be implemented in the future. In discussing drivers, events, and locations, the issue arises as to occurrence o f the same set of drivers at different locations. Such a scenario raises the possibility that the same risk event (e.g., slope failure) may occur at several different locations. This begs the question as to whether such events should be treated as one single event or as a set o f separate risk events. In some instances the events at the different location may not be totally independent from the viewpoint o f the probability of occurrence, such as is the case o f 'slope failure' that could occur simultaneously during a period of heavy precipitation that is spread over several locations. In other instances, events such as 'Archaeological remains encountered' may be fairly independent. Additionally, even in instances where the events are not wholly independent, the consequences in terms of the impact upon performance measures maybe quite different. Thus, i f treated as a single event the burden w i l l be placed upon the users in estimating the probabilities and consequences associated with a combination o f events, a rather unattractive solution given that decomposition rather than aggregation is considered as producing more accurate outcomes in uncertainty analysis (Ravinder et al. 1988). Therefore, given such arguments, similar risk events are modeled as separate risk events within K R I S . Therefore, i f in the example shown in Figure 47 the user believes that there is a possibility, albeit slight that the event may also occur at the site of the west end approach, they are able to define another risk event that relates to such an eventuality. Discussion of the 'Remove' and ' A p p l y Condition' commands that can be executed using corresponding buttons shown in Figure 47 warrants revisitation o f research question 1 dealing with the respective roles of the computer and the user. The functionality provided by the two command buttons is another illustration of the perspective taken by the author in defining the role o f the computer and the role o f the user. A s described, when a user selects a location from the dropdown list, drivers of relevance from each of the project context views that are present at that location are 153 displayed. In a scenario in which the user determines that the risk event deserves consideration, the user can forge ahead with populating other properties of the event. The 'Remove' and ' A p p l y Conditions' are intended to assist the user in this task, i.e., first in deciding on the pertinency of the event and second, given that it is pertinent, in populating other properties. The 'Remove' function relates to the user being given the role o f deciding on the applicability o f individual drivers, and allows the user to remove drivers thought to be inapplicable. Consider the example of a project context component such as the 'western grebe' that is a red-listed 2 0 bird species in the Province of British Columbia and drives the risk issue 'Endangered species' possibly along with other drivers, and is present within the 'Lake ' location of the O L B project. In considering events resulting from the risk issue 'Endangered species' at this location that user may remove 'Western Grebe' from the list o f drivers while retaining other drivers due to the fact that 'Western Grebe' is considered red-listed only when it breeds in an area, a characteristic it does not display at the 'Lake ' location. Thus, in this case the user is allowed to make use of their knowledge in deciding on the applicability o f the drivers. The ' A p p l y Conditions' function allows this role to be passed onto the computer. A s introduced in the previous chapter, a user may encode knowledge in the form of conditions described in terms of the attributes o f a component. In the example being used, the condition could be formulated as 'Breed within area? = True', wherein the Boolean attribute 'Breed within area?' is required to take a value o f 'True' at a particular location for the condition to be satisfied. In executing the 'App ly Conditions' function, the status of the condition is checked by the system and the user is appraised o f the result as shown in Figure 48. In scenarios in which the conditions are not satisfied the user is given the choice o f removing the driver. The refinement o f drivers continues in such a manner considering each driver individually with the ultimate result being the set o f drivers that The province o f Br i t ish Columbia adopts a ranking system for species based on their r isk o f extinction. The stringency o f impact mitigation measures required is a function o f the ranking o f a species among other factors. A red-listed species includes any ecological community, and indigenous species and subspecies that is extirpated, endangered, or threatened in Br i t ish Columbia ( B C Min is t ry o f Sustainable Resource Management 2002) 154 the user wishes to consider in populating other properties of the risk event. A n instance where all drivers are inapplicable at a particular location implies that a risk event cannot result from the risk issue being considered. Thus, within K R I S an event is required to have at least one driver for it to be modeled, or is required to be removed from the hierarchical listing o f risk issues and events, or made inactive, a feature described later. [ Description R i ; k Driers j Mea:ures Affected | Value; ] Mitigation j Standard RIR Record-, j Proiect Records | Memo j Path SRR EXTERNAL PHYSICAL NATENV ENDANGER-Code- jRELOC Description- (Species requited Jo be relocated Type II j J 1 R r k Dtiverc ftom Envitonmental View 1 J ft Location LAKE j»J Risk Drivers from Physical View Path De;cription_ EN^jSJiiVgl...j Aechmophorus occidentals • Western Grebr i^Sfr*~~ - V 5 - * " *'jh*"" " '• "^to>- f^fi* Path Description I'Conditionsfar'e'not satisifeH at current*location?Remove.RtskDriver from'list?" Yes No UtiL'L'liptlUIL T I note jr, Apply EoRditjo-i riizalional View ". I < 5)1 OK Cancel Figure 48. Evaluating the Status o f Risk Conditions at a Location The modeling o f the drivers o f risk events and issues, in an explicit manner as described above has not been attempted in any o f the approaches currently available, as reported in the literature. Whilst subsequent to reading the commentary above, the concepts, the information content, and the interfaces may seem obvious to the reader, it is emphasized that the end result arose out o f overcoming several challenges and in making decisions under circumstances where the optimum choice was not always obvious. In addressing the modeling task, the challenge faced at the outset was in understanding the causes o f the risk issues in an infrastructure project and in developing a set of definitions that could 155 explain the phenomena. Uncertainty and risk are topics that have received extensive research attention. However, as has been emphasized throughout, attempts to explicitly model the sources of risks on infrastructure projects are almost non-existent, as are clear cut definitions that could be used in explaining the phenomena. Once this issue was addressed as described in Chapter 3, the next challenge was to devise a means o f localising the driver-issue interactions such that personnel involved in the risk management task can get a better handle or focus rather than being mired in a myriad of representations, given that there is a multitude of drivers and also given that the driver-issue relationship is not necessarily one-to-one. Thus, the concept of gateways (implemented as locations) was bom and is also unique from a risk management perspective. Decisions were also required to be made along the way as to how similar risk events should be treated as explained previously and as to whether risk driver information should be displayed and be made editable through the project risk view. In the case of the latter issue, it was decided that risk driver information should be displayed on the project risk view to assist in the thought process of the users by apprising them of the components driving the risks enabling them to make better assessment o f the events that could arise and the consequences of the events and so forth. A similar rationale was followed in making the driver list editable as described previously. The answers to these challenges required an effort that was iterative in nature and the opportunity is taken to reiterate the contribution of the research in modeling the driver-issue-event phenomenon. 5.1.4 Performance Measures The primary motivation for carrying out economic risk management is the desire to control the risk exposure of an organization. This is achieved by identifying, quantifying, and responding to the impact o f risk events on project performance measures, both at the work package level and at the overall project level. The impact upon project performance measures is a function o f the nature o f the risk events. For example, a risk event such as high short term inflation o f the C P I is l ikely to have an impact on performance measures such as cost and revenue, while being unlikely to have a direct impact upon a measure such as safety. Information regarding the performance measures that are affected by a 156 particular risk event is modeled within K R I S , with time, cost, revenue, scope, safety, and quality being the performance measures considered. In the K R I S implementation the user can select one or more measures affected for each risk event as shown in Figure 49. The concept o f an impact is relevant primarily to risk events, and thus functionality for recording content regarding performance measures has been implemented only for components at the Event level of the hierarchy. Project Risk Description] Risk Drivers Measures Affected J Values] Mitigation] Standard Risk Records j Project Records ] Memo! Path: REG.EXTERNAL.PHYSICAL.GEOLOGICAL.EARTHQUAKE. Code: jQUAKEDA Description: {Earthquake damage to facility during construction Type: ] Performance measure Methods for estimating likelihood / consequence Methods for incorporating risk into economic analysis *"•»•*• ~J U " of frequency data from p st project ; • 1 I tme <~ ! > F Cost PI Elicit estimates from experts ! • ! Define as a new random variable in the ecora * ^ r — M M M — f l Hill 1 fl! il J j l f~ Revenue • • I IflHHHHBHHB !l > F~ Scope P it project;-*-' • : i m l"~ Quality • st project ; • || MU < mmmmmm: > F Safety PJ Elicit estimates from experts I | Define as a new random variable in the econr. ; 1 Umm H B B H B 9 S B S S 9 K I > Edit | Edit | OK. Cancel Figure 49. Modeling o f Information and Knowledge Related to Performance Measures Once it is identified that a certain risk event is l ikely to affect a primary performance measure, it becomes necessary to measure the extent of the impact and incorporate it into the economic analysis in order to determine the effect on global performance measures such as N P V . Methods for estimating the impact on primary measures such as cost or safety include the use o f estimates elicited from experts and the use o f frequency data. The impacts on primary measures can be incorporated into the economic analysis by 157 using approaches such as modelling the impact as a separate work package or as an addition to an existing work package. A s an organization gains exposure to various projects and risk issues and events that afflict such projects, it is also likely to gain knowledge as to the methods that can be used in estimating the likelihood and consequence of risks as well as on methods on incorporating risks into an economic model o f the project. Scenarios such as the modeling o f the above mentioned methods requires that one continuously ponder the research question as to what is the most appropriate role of the computer and what is the role o f the user? In instances such as the 'Influence - Local / Globa l ' field in the 'Description' tab, the values that the field could take were constrained to local, global, or N / A , as all possible states such a property could take on could be readily identified. The question arises as to whether properties such as methods that can be used in estimating likelihood / impact should be constrained or should the role for maintaining and enhancing a list be passed on to the system users, aided by the computer. The philosophy that has been adopted thus far is that in instances where it is l ikely that an organization would continue to keep on encountering novel information and knowledge elements (i.e., the universal set of elements or values that pertain to the scenario cannot be identified readily), such scenarios would be accommodated by: allowing flexibility for the users to add / edit such content. Thus, the 'Methods for estimating likelihood / consequence' and 'Methods for incorporating risk into economic analysis' are modeled within K R I S as sets that are user-definable, and from which one or more entries can be selected based on their applicability to a certain risk event. For example, in the case o f the risk event shown in Figure 49, 'E l ic i t estimates from experts' has been selected as an appropriate means of obtaining the safety consequences should the risk event 'Earthquake damage to facility during operation' be realized. A related issue that arises pertains as to whether the set of methods should be unique to each performance measure within a risk event, shared between all performance measures within a risk event, generally applicable to one performance measure irrespective o f risk events, or shared between all types of risk events and all performance measure. Whi le some methods such as the use o f a mathematical model may not be applicable to all types of risk events they could certainly be applicable to several 158 performance measures and also to several risk events. Thus, the list o f methods have been modeled as two common lists (one each for 'Methods for estimating likelihood / consequence' and 'Methods for incorporating risk into economic analysis') that are available to all risk events and all performance measures. However, the ability to allocate methods to each performance measure separately has been incorporated to allow for possible differences in the strategies that may be adopted in estimating / incorporating the impact upon each performance measure. It is noted that the use of common lists from which entries can be chosen has the added advantage of allowing consistency to be maintained throughout the population of risk events and performance measures. The set of methods can be augmented by the user as shown in Figure 50 using the 'Edi t ' button within the 'Measures Affected' tab, and are stored within the system in a manner that they are available to all projects modeled within the system. 159 'roject R i s k Description) Risk Drivers Measures Affected j Values | Mitigation] Standard Risk Records ] Project Records j Memo! Path: REG.EXTERNAL.PHYSICAL.6E0L0GICAL.EARTHQUAKE. Code: jQUAKEDA Description: (Earthquake damage to facility during construction ^^^B|j|jjjgjj|jj|J^HHHHHHta Type: (Event jJ Performance measure Methods for estimating likelihood / consequence Methods for incorporating risk into economic analysis C Time W Cost f" Revenue I - Scope P* Quality F Safety • • ' 9 E 9 B H E i H n £ S l j M Elicit estimates from experts > • • ^ •-: I H B B H > • : B l B H B B B H B B H B B B > > Tvl Elicit estimates from experts — • ! > < 0 Define as a new random variable in the econt • < • < Edit ~J Define as a new random variable in the econt * BflHflHBHHHB . M Edit 1 OK Cancel Method Description Use of frequency data from past projects Elicit estimates from experts m Add ] Delete j Edit j Close j Add method Figure 50. Augmenting Lists of Methods of Incorporating Risks into Economic Analysis and Methods o f Estimating Likelihood / Consequence 160 5.1.5 Risk Mitigation Strategies that can be used in mitigating the impacts of risk events upon project performance measures include seeking additional information in order to reduce uncertainty, re-design of project features, and obtaining insurance. The use of such strategies w i l l result in a re-distribution of risks among project parties through risk allocation and a reduction in the anticipated likelihood and / or consequence of risk events. Thus, in providing input to the P S C in the case of the government, or in incorporating risks into a bid by the private sector, one would require information about the strategies that are l ikely to be adopted, as well as with whom the responsibility for the risk is likely to finally rest. Also o f interest are the stakeholders l ikely to be affected by the risk irrespective of with whom the responsibility lies for managing the risks. In attempting to model risk mitigation measures, one o f the issues that needed to be addressed was whether the strategies should be modeled as applying to the risk event as a whole, or should the modeling be at the level of performance measures. The differences between the mitigation measures that are applicable for the various performance measures make a compelling argument in favour o f modeling the measures separately. For example, a strategy such as carrying a duration contingency would be an applicable strategy for the risk event slope failure. However, such a strategy is o f little applicability in considering safety, a measure much better served by a strategy such as devising an evacuation / search and rescue plan. Thus, the decision was made to model the individual sets o f appropriate mitigation strategies that are applicable to each affected performance measure separately as shown in Figure 51. 161 ? x Description | Risk Drivers j Measures Affected j Values Mitigation j Standard Risk Records ] Project Records ) Memo | Path: REG.TECHOP.OPERATION.ACCIDENTS.TRAFFIC. Code: JAZARDOUS Description: [Accident involving hazardous material transport Type: | : Risk event specific list Appropriate mitigation strategies for: Time E3" Operational Restrictions 'BVIE Restrict HazMat transports to off-pea v Modify Appropriate mitigation strategies for: Cost Iii Contingencies 33 Operational Restricj Associated Mitigation Measures Mitigation Master List: Edit Appropriate mitigation strategies for: Time It! i~l Communication A ffl f~J Scheduling B 0 Operational Restrictions ; 0 Restrict HazMat transports to off-peak hours T~| Speed limits I 11 nsi jrAnr.p I Rnnriinn HHHMI^ H OK Cancel Figure 51. Assigning Appropriate Mitigation Strategies to Risk Events on a Performance Measure Basis Similar to properties such as 'Methods for estimating likelihood / consequence' discussed in the previous section, an organization is likely to keep on devising novel mitigation strategies as it gains expertise on different projects. Thus, allowing an organization to build up a repository o f mitigation strategies can be considered as useful. However, the list o f mitigation strategies can also become fairly lengthy, making it difficult to adopt a strategy similar to the one adopted in modeling 'Methods of estimating likelihood / impact', whereby the methods are in one single list from which a user can select appropriate entries. Therefore, the author has turned to the use o f categorization o f the mitigation strategies, a strategy also adopted in the literature to some extent. The 'Mitigation Master Lis t ' in K R I S allows a categorized list o f mitigation strategies to be built up as shown in Figure 52. The master list is common to all risk events, and 162 strategies that are applicable for each performance measure impacted by a risk event can then be selected from the master list. Description] Risk Drivers] Measures Affected | Values Mitigation j Standard Risk Records | Project Records | Memo Path: REG.TECHOP.OPERATION.ACCIDENTS.TRAFFIC. Code: jAZARDOUS Description: jAccident involving hazardous material transport Type: [~ ~ j - Risk event specific list -— | Appropriate mitigation strategies for: Time i+i Operational Restrictions Modify Appropriate mitigation strategies for: Cost S3* Contingencies t r+] Operational Restrictiot Mitigation Master List: Edit i-i Hedges / Guarantees Studies Financing strategies Safety workshops / Training Contingencies Design ) Specification I Construction Strategies Security Increased use of surveillance Communication Scheduling d ste it Add at same level Add at sublevel Delete Edit Close Master list of mitigation measures Mitigation Measure Increased use of surveillance Description OK Cancel Figure 52. Master List o f Mitigation Measures 163 The decisions one should make in structuring a list such as the master list o f mitigation methods or the methods o f estimating likelihood / impact, i.e. should categorization be allowed or should a single linear list be adopted, once again serve to highlight some o f the challenges faced in answering the research questions. The answers are not obvious, nor are there any guidelines as to how information can be structured to assist with the thought process o f personnel involved in the risk management process, unlike the substantive literature that provides guidance in carrying out risk management. Thus, such decisions have been made by considering the pros and cons o f the choices available, and selecting the choice which in the author's opinion provides the best solution. A s introduced at the beginning of this section, information related to the project stakeholders most suited to manage the risk or alternatively the project party that is l ikely to end up with the responsibility for the risk, as wel l as the project stakeholders affected by the risk, provide input to decision making processes. In modeling these properties, the user is given access to components of the project organizational / contractual view from which an association can be made with components that describe relevant stakeholders as shown in Figure 53. The use of components from the organizational / contractual view instead of allowing the direct definition o f values of such properties is another example of the effort to ensure consistency among the models of the five project views. 164 Project Risk \J./-x Description j Risk Drivers J Measures Affected j Values Mitigation | Standard Risk Records j Project Records j Memo Path: REG.TECHOP.OPERATION.ACCIDENTS.TRAFFIC. Description: JAccident involving hazardous material transport AZARDOUS Code: Type: j- Z3 r Risk event specific list i Appropriate mitigation strategies for Time Operational Restrictions Appropriate mitigation strategies for: Cost Modify [+j Contingencies ffl Operational Restrictions Appropriate mitigation strategies for: Safety Safety workshops I Training ffi Contingencies B Operational Restrictions Modify Mitigation Master List: Edit Project parties affected by risk N001 Concessionaire G005 BC Ministry of Environment G008 City of Kelowna Add Project parties best suited to manage risk Delete Edit N006 Facilities Manager N001 Concessionaire Delete Edit OK Cancel Project Kisk Urgamzationa ° " 7 «. L  1 X Organizational / Contractual: N001 Concessionaire f j G000 Government "•BIN000 Concessionaire & P000 Public Stakeholder Groups I P001 Chamber of Commerce - Kelowna ; P002 Chamber of Commerce - Westbank I- P003 T rade G roups • B C T rucking Association V < > OK Cancel Figure 53. Model ing the Project Parties Affected by Risk and Parties Best Suited to Manage the Risk Event 1 6 5 5.1.6 Values Ultimately, an organization's interest lies in identifying the impact of risk events on the project parameters such as N P V . A s described previously, such parameters are calculated with the aid o f cash flow models to which impact of risk events serve as input. In attempting to model such values, among the first issues that needs to be addressed is the appropriate form o f the values. The literature suggests a variety o f approaches towards quantifying the impacts of risks including the use of probabilities, deterministic values that incorporate a contingency, and the use o f qualitative forms such as fuzzy logic. The use o f a qualitative method such as fuzzy logic provides the capability for handling values formulated in natural language terms. However, in using tools such as a P S C in decision making, values related to risk events are ultimately required in numerical terms to facilitate incorporation into the cash flow models used. Whi le fuzzy associative maps ( F A M ) provides a means o f converting the linguistic values used in fuzzy logic into numerical values, the derivation o f F A M s that fit the perception of several personnel can be difficult, especially i f the set of personnel is l ikely to change between projects. Thus, while the merit of fuzzy logic in restricted domains is acknowledged, within K R I S a quantitative approach has been adopted. Thus, the question becomes as to whether the values should be modeled as deterministic or as probabilistic. It is noted that in some cases the user may simply wish to input a single value into the cash flow model to describe the impact of a risk event, whereas in other instances the impact may be modeled as a probability distribution with the aim o f carrying out simulation analysis. A s w i l l be described in the following section, both such scenarios have been supported within K R I S . The values that are modeled and the parameters that are derived are best expressed utilizing the probability tree shown in Figure 54. Modeled initially is the probability value associated with the occurrence o f the risk event, for example, the probability of a slope failure (shown as PE i n the figure) or inflation in steel prices. The possible occurrence of such an event could lead to multiple scenarios. In the event of a slope failure, the slope failure could be a minor, moderate, or a major failure. In the inflation example, the scenarios could be high, moderate, or low inflation. Note that in a case such as inflation, the probability o f the event would l ikely be modeled as one as it is l ikely that 166 some sort of inflation would occur. While any number of scenarios could be used in analysing a risk event, the use of three scenarios is widely adopted (Cruickshank and Simm 1998). Probability values signifying the likelihood o f each scenario are therefore modeled (P i , P2, and P 3 ) ensuring that they satisfy the constraint that their summation be equal to one, given that the values are assigned based on the assumption that the risk event has occurred and that the three scenarios encompass all possible outcomes and are mutually exclusive. The input data screen for these data values in the K R I S implementation is shown in Figure 55 and incorporates the constraint described above as wel l as the constraint that P E should lie within the values 0 and 1 (inclusive). Slope failure occurs Slope failure does not occur Minor slope failure Pi P5, P50, P95 estimates P5, P50, P95 estimates P5, P50, P95 estimates Figure 54. Probability Tree Corresponding to Outcomes of Slope Failure Risk Event 167 >IfRisk Event'Occurs; Event'Scenatio Btobabililies-• • Low outcome scenario Medium outcome scenario High outcome scenario 0 75 0.2 0.05) Scenarios Outcomes i f Time Cost ' Revenue, , | , ,SjfQpje>- Ij - QuaWgi OK | Cancel Figure 55. Assignment o f Probability Values for Scenarios Given that an event occurs, the consequence upon performance measures such as cost and safety would l ikely be different and be measured using different metrics. Based upon the user's selection o f the performance measures that are l ikely to be affected in the 'Measures affected' tab, the facility is provided for modeling consequence values for each of the affected measures. Note that we are now at the ends of the branches o f the upper portion o f the tree shown in Figure 54, with the lower portion not warranting further attention as it models the non-occurrence o f the event. The leaf nodes refer to the possible outcomes o f the event such as monetary values associated with a minor slope failure or the number o f worker injuries resulting from a catastrophic slope failure. The question then arises as to whether the outcome values at the leaf nodes should be modeled as a single value, or as a probabilistic distribution, and i f a probabilistic approach is adopted the means that should be provided for its expression. A probabilistic approach has been chosen due to the fact that it reflects the uncertainty associated with 168 such values. For example, an estimate such as between $10,000 and $20,000 that better reflects the uncertainties and difficulties in estimating such outcomes as opposed to modeling the outcomes as a single value, for example o f $12,215. Furthermore, adoption of probabilistic approach does not preclude a user from entering a single point value as w i l l be illustrated. Thus, one is left to devise the means that would allow users to model such outcomes probabilistically. A variety of options are available. The user can be required to provide estimates for the mean and the standard deviation of the values or even higher order moments such as skewness and kurtosis. Alternatively, the user could be required to characterize the outcome based on estimates for percentile values such as "the value that has an equal chance of being exceeded and being unsurpassed" that corresponds to the 50 t h percentile. The latter approach has been chosen as direct estimation of parameters such as the expected value is considered as resulting in inaccuracies (Ranasinghe 1990) in instances where reliance is placed on expert estimates in the absence of actuarial data. The use of the 5 t h , 50 t h , and 95 t h percentile estimates o f the distribution (denoted as P 5 , P50, and P95, respectively) serve as input to robust estimators developed by Pearson and Tukey (1965) that allow the mean and standard deviation of the performance measures to be computed. A n example data set is shown in Figure 56. In this example, an expert has estimated that the cost associated with a major slope failure has a 0.05 probability o f being smaller than $250,000 (the 5 t h percentile), an even chance o f being above or lower than $ 600,000 (the 50 t h percentile), and a 0.95 probability o f being smaller than $1,000,000 (the 95 t h percentile). The elicitation o f such probability values including the elimination of biases is a topic in its own right and is treated in Hora (1992) and Merkhofer (1987). 169 saaajJEjjiiB I U . Performance M easure; Units-: $ Scenario 1 Low Consequence .12500 1  P5 P50 P95 J250  110000 ] 30000 I J50000 J75000 j100000 . -... -"~ _ Calculate 1 , Expected Value "S td Dev 12312.50 • -8888.17 • . High Consequence j250000 f> JG00000 __T J1000000 " Parameters assuming event occurs. " - "Parameters taking into account possible non-occurrence •Risk tolerance level [%] 25 _ _ 75000 00 :609250.00 546S6 88 2734.8,4 15197 57 228256.03 139702 23 33435.66 • Allowance for risk, including non-occurrence, for assigned risk tolerance 1.009.52 Cancel Figure 56. Model ing the Outcomes o f a Risk Event In the case of a user preferring a single value estimate, the same value can be entered for all three percentile values that results in the desired effect. The data values thus modeled are used in calculating the expected value and the standard deviation at the scenario level, i.e., at the leaf node level, at the level o f the node shown as B in Figure 54 that corresponds to values assuming that the event has occurred, and the root node of the tree (node A in Figure 54) in taking into account all possible scenarios including non-occurrence. The values obtained in this manner can be incorporated as input into the economic model o f the project as a probability distribution characterized by its mean and standard deviation equal to the values calculated. Methods such as M C S or moment analysis can then be used in measuring the impact o f the risk event upon global measures such as N P V . Alternatively, and as mentioned, the users can also utilize a single value. Facili ty is provided for deriving a value that corresponds to a specified level o f risk tolerance o f decision makers. For example, the user might wish to use a value that has only a 25% probability o f being exceeded. The input o f the risk tolerance expressed as a 170 percentage allows the calculation of such a value. The calculation is based on an assumption of a log-normal distribution of the performance measure in the case of all inputs being positive, or an assumption of a normal distribution in cases where one or more o f the inputs are negative. The formulas used in calculating these values are listed in Appendix D . The distributions used have the advantage of being able to model long tails. Additionally, the log-normal distribution can model non-negativity and has also been reported as the distribution that most closely models cost of construction activities (Touran and Wiser 1992). However, consensus on the most appropriate distribution does not exist especially when different performance measures are considered. Improvements to K R I S that can be made in this regard is discussed in section 6.3. It is noted that while the methods of calculation and the methods of characterizing uncertainty are not unique to the K R I S approach, the flexibility and capability it provides for deriving several significant parameters in either deterministic or probabilistic form as required can be considered as a useful feature. In enhancing such capability further and in better allowing the users to visualize the various scenarios for which they assign values, future work w i l l be carried out in developing an interface that allows the probability tree corresponding to the risk event to be visualized and populated. The values obtained in the manner described above relate to one performance measure with the procedure being repeated for all performance measures affected by the risk event. Thus, one would end up with sets o f values such as an expected value o f $25,000 and a standard deviation o f $17,000 for the cost performance measure, and a set o f values such as three workers expected to receive serious injuries with a standard deviation o f six for the safety performance measure. The modeling domain reaches its boundary at this point. A n attempt has not been made to facilitate conversion o f data so that they are expressed in monetary terms such as in the case o f worker injuries. Such calculations and modeling require consideration o f aspects such as value systems, and is beyond the scope of this research. The discussion above has outlined the capabilities of K R I S in modeling an array o f inputs and calculated parameters. However, it is noted that modeling such values as well as other properties of risk events such as methods for estimating likelihood is not mandatory in developing a risk profile within K R I S . In some instances, response 171 measures maybe construed for an identified risk without an attempt at risk quantification. A n example would be government passively assuming responsibility for project risk events that relate to an issue such as 'Nuclear warfare' without assigning probability and consequence values. In such cases only relevant fields such as the parties affected by the risk may be populated. 5.1.7 Project Records, Standard Risk Issue Records, and Memos The properties modeled within these tabs are the same as those within corresponding tabs of E B S components and were previously described in the preceding chapter. 5.2 The Risk Profile The discussion thus far has primarily dealt with research question 2 as to how can the set o f risks that pertain to an infrastructure project be modeled. In developing the answer further and also in answering research question 4 as to how can the representations o f project risks, their properties, and the relationship with the project context be exploited in order to gain additional insights that can assist in the decision making process, the scenario o f a risk workshop is briefly re-visited. A s described in Chapter 3, tasks such as identification and assignment of values are carried out in an iterative fashion at a risk workshop which can take place over multiple sessions. The workshop participants frequently switch between different risks, examine project information as wel l as information from external sources, and can also edit the listing o f risks and their properties. In some instances risk issues that were originally thought of as being relevant could be deemed to be irrelevant or be left in limbo to be examined further later within the session or at a later session. The question then becomes how the model of the project risks can be refined further to support such realities. Several additional functions have been incorporated into K R I S for this purpose and include the 'Set as inactive' and 'Set as active' commands. The 'Set as active' command signifies that the risk component is deemed to be relevant to the project at hand. B y default, a risk component defined by the user is set as active. However, as the risk management process progresses it may be marked as 172 inactive, a functionality provided by the 'Set as inactive' command and which signifies that the risk component is deemed irrelevant. Within the P R R hierarchy, active components are identified by a black icon next to the components in the hierarchy, which is replaced by a grey icon when a component is set as inactive (see Figure 57). A t this juncture, one may ponder the possibility of deleting the component, an action that appears as an obvious option in the case of a risk component being irrelevant. However, retaining such components, albeit marked as inactive, offers value. A change in project circumstances such as a design change may result in a component being reconsidered, a scenario better served by an inactive component rather than one which has been deleted. However, at later stages o f the risk management process, users may wish to view an uncluttered and refined profile of active risks. Supporting this task within K R I S is the functionality for suppressing inactive risks through the use of the ' V i e w active items only' command as shown in Figure 58. 173 Qi File Pro jecM/ iew -Igmpfegiji^ Standards Risk .Window Help , / . JS^P [Xjl & O !%o % X m ^ Q-B- B R E G Register Project Risk Register - OLB Project MGTORG Category Management / Organizational Risks &B EXTERNAL Category External Risks B B POLITICAL Subcategory Political Risk ES;B ECONOMIC Subcategory Economic Risks B-B i CULT-STAKE Subcategory Cultural / Stakeholder Risks B • B PHYSICAL Subcategory Physical Environmental Risks ! B B GEOLOGICAL Class Geological Risks Q LANDSLIDES Issue Landslides . i S B EARTHQUAKE Issue Earthquakes SINKHOLE Issue' Sinkhole B- B GROUNDCONT Issue Ground contamination] B B HYDROLOGIC Class Hydrological Risks ; B B LANDUSE Class Land Use Risks H - | : M E T E O R O L O G Class. Meteorological Risks : i - | ' 5 P E C H A B I T Class .Risks related toSpecies and B - | R E G U L A T O R Y Subcategory Regulatory and Legal RJ B B TECHOP Category Technological / Operational Risks Add at same level Add at sublevel Set as Active Set as Inactive Delete Edit 'Ready Figure 57. Differentiating Between Active and Inactive Risks within the Risk Profile 174 a'-Cfy File Proiect View ipiaq Standards (3Sv< Window : Help *r3 lO *%n B" I. . j Component View all Report B B R E G Register Project Risk Register - Oj[ B B MGTORG Category Management / C) B B EXTERNAL Category External Risks S B POLITICAL Subcategory Political Risk El B ECONOMIC Subcategory Economic Risks E] B CULTSTAKE Subcategory Cultural / Stakeholder Risks • B PHYSICAL Subcategory Physical Environmental Risks • S • B GEOLOGICAL Class Geological Risks ! B B EARTHQUAKE Issue Earthquakes S B GROUNDCONT Issue Ground contamination El | HYDROLOGIC Class Hydrological Risks El B LANDUSE Class Land Use Risks H B METEOROLOG Class Meteorological Risks H - | 5 P E C H A B 1 T Class Risks related to Species and Habitat B3 B REGULATORY Subcategory Regulatory and Legal Risks B B TECHOP Category Technological / Operational Risks View only active risk items. Figure 58. Filtering of Inactive Risk Components of the Project Risk Register In devising such functions, consideration also needed to be given to the role of risk drivers, and the hierarchical nature o f the P R R . A driver-issue relationship necessarily suggests that a risk issue is driven by a component of the project context, and thus is relevant to the project. Therefore, all risk issues that are assigned drivers are automatically signified as being active. Furthermore, in order to distinguish such components from issues that have been deemed to be active but have yet to be examined in detail and be assigned drivers, a red oval appears within the black icon signifying active status. The modeling o f the driver-issue relationship between individual components of the project context views and risk issues / events and the visual 175 representation of the existence of such relationship within the risk profile also enables the changes that occur in the risk profile due to changes in the project context to be easily identified. The composition of the project context can change due to reasons such as design changes, selection of an alternative site, and changes in government. A s components are added and / or removed to reflect these changes within the project context views o f K R I S , some risk issues and events may gain drivers whereas in other instances an issue or event may become devoid o f drivers. For example, in the O L B project several alternatives were considered for siting the graving dock. A n area of archaeological interest exists within the Bear creek site, one of four sites initially considered. However, such an environmental component does not exist within Kelowna city park, alternative site for the graving dock. Thus, as one moves from representing the Bear creek alternative to representing the city park by removing the E B S component that models the archaeological area, the risk issue 'archaeological remains encountered' would lose one of its drivers, and i f no other drivers exist the risk profile would automatically undergo a change from the one shown in Figure 59-A to Figure 59-B, allowing the user to easily identify pinpoint the differences in the risk profile. In the current implementation the change is displayed visually through the absence / presence of the red dot within the icon next to a risk component. Future work anticipated includes enhancing the visual representation by strategies such as changing the intensity of the color o f the icon based on the number of drivers. It is also noted that should E B S components from the standards side be used in representing any additions that occur in the project context as one moves from one alternative to the other, the associations that exist between the components and risk issues on the standards side w i l l automatically be re-generated on the project side allowing users to identify any additions to active risk issues. This process is further described in section 5.4, whereas the modeling of the Sea to Sky highway project illustrates this functionality (see Chapter 6). 176 l O l File Project _view ifemplatei.'-'ieW, Standards .Risk .Window Help el * B-1 m u (A) REG Register Project Risk Register - OLB Project • B MGTORG Category Management / Organizational Risks •J EXTERNAL Category External Risks H "B POLITICAL Subcategory Political Risk B- B ECONOMIC Subcategory Economic Risks H-B CULTSTAKE Subcategory Cultural / Stakeholder Risks B- B PHYSICAL Subcategory Physical Environmental Risks i [±l-.B'GEOLOGICAL Class Geological Risks i . B B HYDROLOGIC Class Hydrological Risks I B B ; L f t NDUSE Class Land Use Risks B •• B FNARCHAEO Issue First nations archaeological sites B ARCHREMAIN Event Archaeological remains encountered: B AVAILABILI Issue Availability of land ' • H•• B METEOROLOG Class Meteorological Risks '•• B B SPECHABIT Class Risks related to Species and Habitat 1+1 B REGULATORY Subcategory Regulatory and Legal Risks B TECHOP Category Technological/Operational Risks Ready I'll1' "H 'i M , H | I I , M I I | [ : M ; - T . . . . . . i » J - J . j0[File Prb'jectiView Tgprfe'-e j^BiJtr Standards Risk Window - Help '_ _ _-J a-(B) B - B R E G Register Project Risk Register-OLB Project : B - | : M G I O R G . . Category Management/Organizational Risks B B EXTERNAL Category: External Risks B ' B POLITICAL Subcategory Political Risk H B ECONOMIC Subcategory Economic Risks : H B CULTSTAKE Subcategory Cultural /.Stakeholder Risks B-- B PHYSICAL Subcategory. Physical Environmental Risks B B GEOLOGICAL Class Geological Risks : • H B HYDROLOGIC Class Hydrological Risks : R - | l / W D U S E Class Land Use Risks . !:-•;•: a B FNARCHAEO Issue First nations archaeological sites :;-B ARCHREMAIN Event Archaeological remains encountered B AVAILABILI Issue Availability of land :•••)' R B METEOROLOG Class Meteorological Risks • • R) - B SpECHABIT c ' a s s Risks related to Species and Habitat B" B REGULATORY:, Subcategory Regulatory and Legal Risks H-B TECHOP Category Technological/Operational Risks .:. R e d d y Figure 59. Representing the Change in the Risk Profile due to Underlying Changes in the Project Context 177 The hierarchical relationship between components also comes into play in determining the effects on the tree as intermediate or lower level components are either signified as active or inactive. The logic that has been adopted is to mark all components below the component, as well as all components above along its path in the hierarchy as active should a component be set active, and to mark only the components below as inactive should a component be set as inactive. The goal has been to ensure that whenever an active component exists at a lower level, the path leading to the components stays active, an important consideration given that the hierarchy can be folded or expanded. The logic adopted ensures that in expanding a folded tree, a user is given guidance as to where active components can be located. It is noted that issues that have been assigned drivers, its child events, or the components along the hierarchy that lead to the issue cannot be set as inactive without first removing the risk drivers with the thought process being that i f an issue is being driven by a context components, it is applicable to the project at hand. Once users define the categorize listings and populate the properties of risk components, they may wish to examine the nuances of the project risk model in further detail. For example, users may wish to derive insights from a partially completed model and use the insights gained in refining the model further. Such issues bring into play research question 4 which is how can the representations of project risks, their properties, and the relationship with the project context be exploited in order to gain additional insights that can assist in the decision making process? The ability to visualize the active and inactive risk components is an initial step in answering this question as it allows decision makers to compare the risk profiles for several project options and visualize the transformation that occurs between active and inactive risks. Prior to continuing the discussion about the strategies adopted in answering research question 4, it is worthwhile to ponder some of the decisions that require support from a model of project risks. Among such decisions could be the selection of alternatives that minimize the overall risk profile, and the selection of options that shift the risks from one stakeholder to another. In making such decisions information such as the components driving the most risks, the risk issue driven by the most number o f drivers, and risk events that have an expected cost outcome o f greater than a certain dollar amount are l ikely to be particularly helpful. The use of querying functions such as selection and 178 sorting of components based on user-specified criteria that have been devised in support o f such decision-making is described in the following section. A l so briefly described is the use o f visualization strategies that could be used but are not currently implemented. It is reiterated that while the implemented functions serve to illustrate aspects o f the functionality ultimately desired, the primary research contribution lies not in implementing such functionality but in the development of the concepts including means o f maintaining consistency that facilitate such functionality. 5.2.1 Reporting Function The simplest form of the reporting function allows users to generate a report o f all risk components or a subset as shown in Figure 60. The contents that should appear in such a report can be defined through the 'Content profile' function that allows the user to select the information that is required to appear in the report (see Figure 61). i C All Rick Issues t Selectively '\C> Select-Sort. - , " .". • . ,.'.'» h 1 1 i t EkfJJ SRR" Standard Risk Issue Register , ; • : El O MANAGEMENT. Management / Organizational Risk i a••[£] PARTNERSHI PartnetshipManagementRisks [~J STAKEHOLDE Stakeholder Management Risk UJ CORPORATE Corporate Management Risk 3 • C O N T R A C T U A Contractual Risks i- a • SURPLYMGT Supply Management Risks (+)••• EXTERNAL External Risk •• B O TECHN0L0GI Technological/OperationalRisk +! • CONSTRUCTN Construction related risks : , • DESIGN Design Risks B•••-PERFORMANCE Performance related Risks Report-Content Profile^  » D etme R eport Content Profile - Print ill a Cancel Figure 60. Selection of a Subset o f Risk Components as Targets of the Reporting Function 179 \~\ 142 Appropriate mitigation strategies for Safety Q 57 Project parties affected by risk '•• [~J 57 Participants responsible for risk r @ 35 Values/Statistics Filled Values/Statistics for Time Filled 71 Values/Statistics for Cost Filled Values/Statistics for Revenue Filled :" 0' 71 Values/Statistics for Scope"",FJIIedj • — • ^ - - - ^ ContentsVidth: • • Status ''•'•''<' ' , X- , ; ''^*"BK'" • | | " ' t C a n c e l \ Figure 61. Selection o f the Content of a Risk Report The report that results can be printed out in hard copy form with functionality for use of a variety o f paper sizes such as 11" x 17". While the function described may seem mundane, it does provide considerable value, especially as ultimately the fruits o f the risk management process are required in the form of a document. The function also allows reports to be generated that can be distributed to workshop participants at the end of the risk workshop session as a means o f summarizing the stage at which the process is at, and as an aid in further thinking about the risks. More refined querying ability is provided by the 'Select-sort' function. This function allows users to specify a set of selection criteria that are used in determining the components that are to be included in the report as wel l as allowing the specification o f the order by which they should be sorted. The conditions can be defined by concatenating a number o f individual conditions using the A N D / O R operators. In the example shown in Figure 62 conditions that result in a report o f risks driven by environmental components and have cost consequences are specified. 320 180 =Name: Risks Driven by Env Drivers having Duration Consequences Add Delete R.. N. . Key Condition Value 1 fcVakit 'AND Risk Driver • Environment... EQ ENV i M. Edit If r } OK Cancel iRisks Driven by Eny>Drivers having Duration Consequences 'Relation: .JANDJ^jj ' H' Not Modifier" :Key: •. | Performance measure affected Condition: Value: i i S EO Time . Revenue Scope Quality Safety. o k Cancel Figure 62. Specification of Select Conditions for Generating Risk Reports 181 The specification o f sort conditions is shown in Figure 63, with the components being sorted according to the project phase in the example. Events Key fphac Order I IIESLIJL f - - G r o u p * ' ; OK Cancel Figure 63. Specification of Sort Conditions for Generating Risk Reports A s described, the reports generated are in the form of text reports, with examples from the O L B project being presented in Appendix A . The output that results from such queries can also be used in visualization schema. For example, the results o f a query that outputs the responsibility fields of risk events driven by environmental components, sorted by project phase can be used in producing a visual image such as the one shown in Figure 64. While such functionality has not been currently implemented it is part o f future work that is being considered. 182 Figure 64. Visualizing Distribution o f Risk Events across Phases and Responsibility 5.3 Standard Risk Register The derivation of the P R R in the manner described above relies heavily on the experience and knowledge of the individuals involved with the process. Furthermore, information used in the process such as the set o f mitigation measures that is adopted tend to be re-used between projects. In the previous few sections, some instances where mechanisms for information accumulation have been incorporated within K R I S were identified. Specifically, this involved the creation o f master lists of mitigation measures, methods for estimating likelihood / consequence, and methods for incorporating risk into economic analysis that can be developed and made use o f on different projects. The following discussion relates how K R I S goes further in answering research question 5. In doing so, focus is kept on the overall philosophy o f the approach which is to assist the user in thinking about the applicability o f risk components to a project, in thinking about the mitigation strategies that could be adopted, the probability and consequence values that are applicable and so forth. The intent is not to provide answers to the users but to assist the user in arriving at such answers. 183 To recap, research question 5 was: What is the information and knowledge content that can be re-used between projects? H o w can such content be archived in a project neutral format? How can issues such as the lack o f standards in describing risks / aspects o f the project and the need to allow ongoing build-up of content be overcome? How can the content from past projects be extracted from the archives and what sort of assistance can be given to the user in deciding the appropriate content to re-use? A s described in Chapter 3, the modeling of risk components in a project-neutral format is carried out within the standards side of the risk view. The structure used for this purpose is termed as the Standard Risk Register (SRR). The S R R is based upon the same hierarchical architecture as the P R R and is intended to be populated with project-neutral risk components over a period o f time as an organization undertakes projects. Thus, i f the O L B project is the first project modeled within K R I S by an organization, the risk hierarchy identified in the P R R would be duplicated in a project-neutral format within the S R R at the end of the project, thus making the information and knowledge gained during that project available for re-use. A s an organization continues to encounter novel risk components they w i l l be added to the S R R gradually building up the organizational corpus o f risk information and knowledge. The definition of a S R R in this manner allows an organization to retain a standard vocabulary that describes risk components and their properties. It is stressed that flexibility is provided within the K R I S architecture for an organization to develop their own nomenclature and categorization approach. In the current implementation, addition of components to the S R R has to be carried out by re-entering the component information on the standards side. It is anticipated that in the future functionality w i l l be added to the P R R such that a selected component can be added onto the S R R directly from the P R R itself, thus reducing the need to re-enter information. The question that arises next, and which relates to the initial part of research question 5 is what information and knowledge should be passed onto the standards side? The answer to the question, as is the case with many of the hurdles faced in the research, is not obvious, and is more readily described in terms of the information and knowledge discarded. The information contained within the 'Project Records' tab are references to project specific information. Thus, in defining S R R components in a project-neutral format, the 184 details of associations with project records that are contained within this tab are are discarded. The other information discarded in this manner are those of the 'Values ' tab. Probability and consequence values are highly project specific and are also dependent upon the perception of the personnel involved. Even in instances where personnel recur between projects, their beliefs and estimates o f the probabilities and consequences associated with a risk event may change as a result of new experiences. While it can be argued that the same might be true for a property such as the mitigation measure that can also depend on the perception of the users, an important difference is that such properties are less susceptible to changes in the context, whereas values depend heavily upon the particular combination of drivers that exist on a particular project. Support for estimating values is better served by archiving information related to the actual outcomes of risk events should they occur, an extension discussed in Chapter 6. It is also noted that within the current implementation of K R I S , the 'Risk drivers' tab is not shown on the standards side. Knowledge regarding the driver-issue associations is created on the standards side through the environmental and other project context views (see section 4.3.7). It is anticipated that the shortcoming of not being able to visualize the associations through the risk view w i l l be overcome as improvements are made to the computer implementation of K R I S . A l l other information and knowledge modeled within a P R R is reproduced in the S R R including content related to the performance measures affected, the appropriate mitigation measures for a certain performance measure of a risk event, and appropriate means for incorporating risk into the economic analysis. Thus to summarize, the S R R provides an architecture to model risk components in a project neutral format. Components can be categorized hierarchically matching the risk categorization scheme that an organization adopts on infrastructure projects as shown in Figure 65-A. Properties related to risk components that are project-neutral in nature can also be modeled within a frame attached to each component o f the hierarchical risk listing as shown in Figure 65-B. The means by which the contents of the S R R can be re-used on future projects is described in the following section. 185 HI 0 File Project_View TwrMpL<e_Vifjw Standards Standard Risk Window' iHeip- r w , / „ - • . . • .y 2 J j ? . fe a a!»I© r=j. _ B S~ MGTORG Category Management / Organizational Risk l i l PARTNERSHI Subcategory Partnership Management Risks : STAKEHOLDE Subcategory Stakeholder. Management Risk j tE CORPORATE Subcategory Corporate Management Risk jjl- CONTRACTUA Subcategory Contractual Risks SUPPL YMGT Subcategory Supply Management Risks El - EXTERNAL Category External Risk ffi^ \ |±i POLITICAL Subcategory Political Risk \ Lt! ECONOMIC Subcategory Economic Risk . I $ - CULTSTAKE Subcategory Cultural / Stakeholder Risks - ; • 1+] PHYSICAL Subcategory Physical Environmental Risk !+]•• REGULATORY Subcategory Regulatory and Legal Risk 3 TECHOP Category Technological / Operational Risk E - DESIGN Subcategory Design Risks B - CONSTRUCTN Subcategory Construction-related risks |±S - OPERATION Subcategory Operational Risks [<•.." "7 "12 Ready > A Descriphon j Measures Alrected | Mitigation j Standard Ri:k Records j Memo j ^ Path: REG.TECHOP.OPERATION ACCIDENTS.TRAFFIC | Code! 1 ZARDOUS Description:"*JAccident involving hazardous material transport Type- | . Extended Description 1111 ^Accidents involving trucks carrying gasoline, solvents, pesticide etc. (B) ([.Influence - Local / Global ! ' Local-Applicable Project Phase i (Operation "Tj OK Cancel Figure 65. The Standard Risk Register 186 5.4 Derivation of the Project Risk Register Utilizing Content from the Standard Risk Register A n y one or a combination of several approaches can be taken by a user towards deriving a P R R , either exploiting contents of the SRR, or alternatively without the aid of the S R R . These different modes o f use are illustrated in Figure 66 followed by detailed descriptions of the modes that rely on the use of content from the SRR. Mode l D e v e l o p . t h e P r o j e c t . R i s k R e g i s t e r bi-m a n u a l l y b r o w s i n g t h r o u g h t h e S t a n d a r d R i s k I s s u e r e g i s t e r and i d e n t i f y i n g , r i s k i s s u e s t h a t a r e t h o u g h t t o be r e l e v a n t t o t h e p r o j e c t a t h a n d . S t a n d a r d R i s k R e g i s t e r Mode 2 Make use: o f t h e e n c o d e d D r i v e r - I s s u e a s s o c i a t i o n s i n i d e n t i f y i n g e n t r i e s of- t h e S t a n d a r d R i s k I s s u e R e g i s t e r t h a t • a r e . r e l e v a n t t o t h e p r o j e c t . . Mode 3 Make use o f e n c o d e d C o n d i t i o n s i n . r e f i n i n g t h e . D r i v e r -I s s u e a s s o c i a t i o n s . • Use t h e r e f i n e d a s s o c i a t i o n s i n . i d e n t i f y i n g e n t r i e s o f . t h e S t a n d a r d : . . R i s k I s s u e R e g i s t e r : t h a t a r e - r e l e v a n t t o the- ; p r o j e c t . I Mode 0 D e v e l o p the: P r o j e c t : R i s k R e g i s t e r b y d e f i n i n g the r i s k : -:: i s s u e s f r o m s c r a t c h , w i t h o u t u t i l i z i n g t h e S t a n d a r d R e g i s t e r . P r o i e c t R i s k R e g i s t e r . Figure 66. Modes o f deriving the Project Risk Register 187 Mode 0 relates to instances where an organization is yet to develop a S R R that bears a substantial amount of content. In this mode of use, the user defines the P R R in the manner described in the previous sections of this chapter without the use of content from the standards side. A s an organization undertakes projects and goes through the process described above, it w i l l gradually build up its library of risks. The library implemented as the S R R can be made use of in defining the risk profile of future projects reducing the burden on the user, and also enabling re-use of information and knowledge gained on past projects. Modes 1 to 3 are employed in making use o f the S R R in compiling a P R R . 5.4.1 Mode 1 In Mode 1, the S R R is used as a mnemonic device that allows the user to browse through the listing of potential risk issues and select ones that are thought to be relevant to the project under consideration, thus building up the project risk register. In employing this mode, a decision is made that use would not be made of the driver-issue associations between components o f the views that describe the project context and risk components. This mode of use is envisaged in instances where the project is o f a unique nature or in a unique environment, precluding the use of components from the standards side in describing the project context. In this scenario, the components o f the physical, process, organizational, and environmental views would more or less be developed independently on the project side and therefore encoded information relating to the driver-issue relationship would not be available. In employing Mode 1, the user would first import the S R R over to the project side in its entirety. The user would then manually examine each of the risk issues and select ones deemed to be pertinent to the project, by tagging applicable risk issues as 'active' as shown in Figure 57. In addition to the risk issues copied over from the standards side, the user has the flexibility o f defining additional risk issues and events deemed to be applicable, that can later be added onto to the S R R to further supplement the risk library. The user would then manually associate these risk issues with components of the four project context views. Use can be made of the information and knowledge encoded within components copied over from the project side regarding applicable mitigation 188 strategies, performance measures affected and so forth in defining the properties of the components. 5.4.2 Mode 2 Knowledge regarding the driver-issue relationship is utilized in employing Mode 2. Similar to the Mode 1 described above, the user would first import the S R R over to the project side in its entirety. Additionally, use is made of standard libraries of the four project context views in developing the project models for the physical, process, organizational, and environmental views. Thus, this mode is suitable in instances where an organization is equipped with libraries of significance for the risk view as well as the four project views. In copying over components in building up a project context view such as the environment, any driver-associations made on the standard side are copied over. The same association is now automatically reproduced on the project side, now with components of the project risk register. A n y risk issue components that are automatically assigned drivers in this mode of use are tagged as active by the system, thus assisting the user in identifying risk issues relevant to the project. 5.4.3 Mode 3 A s described previously, in some instances the mere presence o f a component does not make the driver-issue relationship valid. It depends on the attribute value of components and this phenomenon is modeled through conditions in K R I S . Mode 3 is intended for cases where an organization in building up sizeable libraries has also encoded conditions for context components. In this mode, the user can make use o f these conditions to screen out drivers that do not meet the criteria set out in the conditions. This information is of value in assigning probability and consequence values as an event driven by multiple components is more likely to occur as well as being likely to have greater consequences. In using the conditions, the risk driver o f a particular view would be chosen and the ' A p p l y Conditions' function executed. The function considers the attribute values of the component that acts as the driver at the particular location and matches these against the conditions that are also specified in terms of the attributes. Should the conditions be not 189 satisfied, the user has the option of removing the driver from the list. Manual removal of the drivers is also permitted as described previously, supporting instances where the user has knowledge that conditions are not ripe for the component to act as a driver but the knowledge is yet to be encoded within the system. 190 6 Validation of the Research One could look at the validation o f the current research from two viewpoints. First, one could take the viewpoint of determining whether the research has successfully met the goals that it set out for itself; while the second viewpoint relates as to whether its use results in an improvement of the risk management process. In addressing the topic of validation, a combination of approaches has been used. Initially, a brief summary of the answers to the research questions is presented. To recap, the questions are: (i) Questions as to the most appropriate role(s) for the machine and for the system users in developing a computer-based methodology; (ii) Questions related to the representation o f risks; (iii) Questions related to representing the project context-risk relationship and the representation of the project context; (iv) Issues dealing with leveraging such representations to maximize the assistance that can be provided to users to derive meaning from the models. For example, to support diagnosis such as the work activities that are most risk prone and the change in the risk profile that occurs as alternative activities are considered; and; (v) Questions relating the content that can be re-used for other projects and the means by which re-use can be facilitated. Research question 1 relates to the role deemed suitable for a computer-based methodology, an issue that relates to the approach as a whole, as wel l as to specific elements of the system. In considering the approach as a whole, the perspective that has been taken is to develop a methodology that can facilitate the application and re-use of information and knowledge, as opposed to a methodology that carries out such a task by itself and is driven to providing answers. A s identified in the previous section, the role of the machine has been delineated to providing the architecture for modeling risk and environmental components. Flexibil i ty has been provided for the user to adopt a nomenclature and classification schema o f their choice, while the machine provides facility to develop organizational-level standards. The need to support a broad range of 191 projects and the lack of standards in classifying and identifying risks and environmental components have greatly influenced the approach taken towards this question. In considering research question 2, functionality has been provided for modeling a hierarchical listing o f risk components with properties being modeled within a frame attached to each component. A core set o f properties has been identified and modeled. The details of the answers to this question are presented in Chapter 5. In answering research question 3, an architecture that allows users to develop a model of the environment has been developed and is presented in Chapter 4. The concepts leading to explicitly modeling the driver-issue relationship are introduced in Chapter 3. Functionality for modeling the relationship has been developed for the environmental view as well as for the physical, process, and organizational views. The capabilities that are useful in exploiting models of the risks and the project context were identified and supported within the implementation in answering research question 4, and are described in Chapter 5. Components of both the risk view and the environmental view o f an individual project are stripped of context-specific properties and stored within the standards side in facilitating content re-use. Several modes o f use o f archived content have been introduced in answering research question 5 and are described in Chapter 5. The discussion above has briefly presented the manner in which the goals that the research set out for itself were answered. Answering the research questions required an effort to optimize the individual solutions as well as the optimality of the overall outcome. Whi le the contribution brought on by responding to the research questions i n isolation would be significant given their incomplete treatment in the state o f the art, the contribution made by answering the questions in unison decisively differentiates and advances it from existing approaches, thus having the potential to greatly assist an organization in achieving its objectives in risk management. In further testing and validating the approach, a full scale project was modeled within K R I S . A second project was partially modeled in testing functionality related to content re-use. 192 6.1 Modeling the Okanagan Lake Bridge and Sea to Sky Projects The O L B project introduced in section 1.6.1 has served as the candidate project for developing a comprehensive model, while the Sea to Sky project was the candidate in developing a partial model. The perspective o f the government in the process o f developing a P S C to aid decision making as to the viability of alternative procurement modes and in evaluating private sector bids in the event of an alternative mode being used has been taken in developing the models. The projects have been modeled making use of public domain information with assistance being provided by the B C Ministry of Transportation in locating certain documentation. Information sources include Bri t ish Columbia Ministry o f Transportation (2003a), British Columbia Ministry o f Transportation (2003b), Coast River Environmental Services Ltd. (1996), Coast River Environmental Services Ltd . (2001), M i n n i (1996), M i n n i (2000), Wakefield Acoustics Ltd. (2001), and Westmar Consultants Inc. (2000). The models reflect the perspective of the author in terms o f the risks identified and their properties. Fairly detailed models have been created to illustrate the capability of K R I S in modeling such detail. It is acknowledged that other users may use a coarser model, particularly during the early stages o f the project. However, as has been emphasized throughout, K R I S is adept at handling varying degrees of detail and the case studies presented should not be construed as a requirement that the modeling should be carried out at such a high level o f detail. The steps involved in the modeling process were: i . Model a diverse set o f risks and project context components relating to the O L B project. i i . Develop a S R R and a S E L making use o f the components identified in modeling the O L B project as wel l as other additional components defined on the standards side. i i i . Make use o f the standards in developing a partial model of the Sea to Sky project. Characterizing the O L B project without the use of standards from any of the views corresponds to a scenario in which an organization has just begun the information and knowledge accumulation process. In modeling the environment o f the O L B project, the environment has been divided into five classes, which are the physical, social, economic, political, and regulatory classes. The components of the physical class, excluding 193 zoological components are shown in Figure 67, while zoological components are shown in Figure 68. A s noted in Chapter 4, use has been made o f standardized scientific names in identifying organisms, while the Canadian Council on Surveys and Mapping standards ( B C Ministry of Sustainable Resource Management 2002) on topographic feature classification have been adopted in the naming of topographical features. The social, economic, political, regulatory components m