5 e Conférence spécialisée sur le génie de la construction

de la Société canadienne de génie civil

5 th Construction Specialty Conference

of the Canadian Society for Civil Engineering

Moncton, Nouveau-Brunswick, Canada

4-7 juin 2003 / June 4-7, 2003

STRUCTURING OF RISK INFORMATION TO ASSIST IN KNOWLEDGE-

BASED IDENTIFICATION OF THE LIFE CYCLE RISKS OF CIVIL
ENGINEERING PROJECTS
Sanjaya De Zoysa, Alan D. Russell
Department of Civil Engineering, University of British Columbia, Canada

ABSTRACT: The process of identifying and managing risks associated with the lifecycle of large civil
engineering projects is a challenging one given their scale and complexity. To date, a practical yet
comprehensive computer-based tool that can assist with this process does not exist. While progress has
been made by various researchers on developing risk management frameworks using IT approaches, we
believe that success depends on developing an approach that treats the environmental, physical, process,
and organizational/contractual contexts of a project in a way that allows system users to capture their risk-
related knowledge pertaining to these dimensions in a reusable and editable format. A review of previous
work conducted by researchers and practitioners alike in developing mechanisms such as risk registers for
encoding risk information provides the backdrop for the identification of requirements for a structured risk
information repository. We then discuss the contents desired of a structured risk issue library that serves
as a repository of generic risk information, and a project risk register that serves as a repository of project
context dependent risk information for use throughout the project risk management process.

1. INTRODUCTION

Governments on a worldwide basis are faced with an insatiable demand for public infrastructure such as
roads, bridges, hospitals, schools, water supply 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. As a result, governments are exploring a greater range of procurement modes in an
effort to meet some of the demands for new or improved infrastructure in a timely way. Many of these
modes can be grouped under the rubric of public-private partnerships, or P3’s. Of particular interest are
those modes (e.g. design, build, finance operate, maintain – DBFOM) that maximize the involvement of
the private sector and which result in the greatest transfer of 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/or create new business opportunities. However, these
firms now find themselves assuming responsibility for all facets of the total life cycle of a project, including
financing, regulatory processes, design, construction, commissioning, revenue generation, operation and
maintenance, and debt servicing. As a result, they must identify and manage a much larger spectrum of
risks – in fact it is this risk transfer that has special appeal to government.

As in other management functions, knowledge and experience are invaluable assets for successfully
carrying out the risk management function. However, knowledge within organizations that resides
primarily in the minds of experienced personnel is seldom documented in a consistent and accessible

COF-470-1
way, and can easily be lost through resignations, downsizing, and retirements. Additionally, the task of
identifying the risks associated with all facets of the project lifecycle, assessing their magnitude, and the
development of response strategies is in itself a challenging task given the scale and complexity of
infrastructure projects. The lengthy time spans associated with the pre-implementation and the
operational stages, the multitude of stakeholders involved, the necessity of dealing with various levels of
government such as local, provincial, and federal in order to obtain approvals and conform to regulations,
coupled with requirements to carry out environmental studies and adopt protective measures, complicate
an already complex task of designing, constructing, and operating a facility that typically contains a vast
number of components and an equally large number of technical and administrative processes and sub-
processes. Thus, computer tools that make use of recent advances in Information Technology (IT) can
play a significant role in assisting in the capture of knowledge gained on a firm’s past projects for re-use
on future ones. This helps to reduce the burden on the project team for analyzing the different aspects of
the project in order to identify and manage all significant risks, and helps to avoid omissions. To date,
such a tool does not exist, although a number of researchers have sought to develop risk management
frameworks using various IT approaches (e.g. Tah & Carr 2001, Niwa 1989). While progress has been
made, we believe that success depends on developing an approach that allows system users to capture
their knowledge in a reusable and editable format, and which treats the environmental, physical, process
and organizational/contractual context dimensions of a project. Consideration of these project dimensions
is extremely important as their attributes and likely values are the determinants of risks that could arise on
a project. In a previous paper (De Zoysa and Russell 2003), we outlined aspects of an approach capable
of treating all of these dimensions. In this paper, we focus on how risk identification knowledge may be
structured and encoded. We build on previous work by others related to the concept of a project risk
register. We are cognizant of the need for a practical approach that embraces the realities of full-scale
projects. 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 of information, the need to work with incomplete
information, and limited resources, including time, with which to conduct the risk management function.

2. CURRENT APPROACHES FOR THE MANAGEMENT OF RISK-RELATED KNOWLEDGE

A logical categorization of risk issues can assist in expanding the risk awareness of project stakeholders,
and also allow common risk mitigation strategies to be developed (Al-Bahar & 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 & Crandall 1990, Erikson
1979, Kangari & Boyer 1987, Leung, Chuah, & Tummala 1998, Perry & Hayes 1985, Tah & Carr 2001,
Wideman 1986). The 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 of 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 in at least two ways – they do not relate to a specific project
type, nor do they relate to the specific dimensions of 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 through the multitude of project physical, process, organizational/contractual, and
environmental components, and match their occurrence to the risk items in the list or vice versa. 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 (Simm & Cruickshank 1998) and construction in rivers and estuaries
(Morris & Simm 2000). In some instances these risks are mapped onto specific construction operations.

A further evolution of the process of managing risk-related information 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, McMahon & Sims Williams 1998). Ward (1999) and the Office of
Government Commerce, UK (2002) 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 well as

COF-470-2
information on the nature of impacts and risk ownership have been suggested as important register
contents by Ward. The Government of New South Wales (2000) suggests potential impact, and an
assessment of the adequacy of existing risk reduction measures as other contents useful for a risk
register. The Department of Premier and Cabinet, Tasmania (2002) stress the usefulness of 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 of 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. Williams (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 a tool that initiates risk analysis and response planning. The register structure suggested by Williams
categorizes 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) that is a Microsoft Access database that allows the user to
track and manage project risks. It allows the input of identified risks, impacts and probabilities in
qualitative terms, and mitigation and contingency steps. 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 of exposure, and the level of risk. SiteRisk
(Anderson & Madsen 2001) programmed in Microsoft Access is another computer tool that employs a risk
register. It contains details on construction activities, risks, and events in different tables. The parameters
are linked through relations in the database. This permits the user to access information across projects,
and activities. The Risk Register Database System developed for the automotive industry (Patterson &
Neailey 2002) contains information such as risk owner, assessments of 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.

While advances have been made in defining the information that should be contained within a risk register,
and in implementing a register as a computer tool, work remains to be done in capturing the information in
risk registers for current projects in a manner suitable for re-use, and for enhancing the thoroughness of
the risk management process. The development of a richer set of attributes that can be modeled in the
risk register, and the incorporation of search and navigation technologies and reporting mechanisms that
can make the contents of the register more accessible can also be considered as desirable improvements.
This is particularly important when dealing with large-scale infrastructure projects in which one encounters
a large, diverse set of risks. While some current risk registers such as SiteRisk and RiskRadar allow risk
events to be assigned specific activities and program areas, the integration of risk event information with
the environmental, product (physical), process, and organizational/contractual views of a project is an area
where significant improvement could be made. Such integration will allow the user to better identify risks
that are relevant to the current context of the project, and also to identify changes in the risk profiles that
could accompany changes in other project views, especially when design changes are made or as more
project information is obtained. Identified here are several guiding requirements for the features desired of
a computer system that allows users to document general risk knowledge and package it for use in
specific project contexts in the form of a project risk register.
(a) Recording of risk information relevant to all stages of project risk management
Proponents of risk register have identified this property as being important. The ability to store
information relevant to all stages in a single repository ensures the consistency and accuracy of the
information flow from one risk management function to another, and from one project phase to
another.
(b) Integration with other project views
As identified previously, project risks are dependent on the context of the project, i.e. its products,
processes, organizational structure, and environment. Integration with other project views allows
dynamic changes to be made to the risk register in accordance with changes in project parameters,

COF-470-3
 and also assists in the creation of search mechanisms that allow the user to identify risks
associated with a particular element of a project view. It also ensures that risk-related information is
consistent with other project information as well as being relevant to the project at hand.
(c) Provision of search and navigation mechanisms that assist in identifying risks of interest
Search mechanisms and queries that assist the user in searching for risks associated with a project
or environmental element, and which allow the grouping of similar risks are essential. Similarly, a
navigation mechanism that allows the user easy access to related information such as risks that are
likely to occur at the same time would greatly increase the comprehensiveness of the risk
identification process. This feature can be enhanced by providing tabular and graphical reporting
mechanisms that detail information associated with user-defined queries and searches in order to
identify the potential clustering of risks in space, time, physical component or organizational terms.
(d) Capability to archive project risk registers and re-use of their information on future project
Risk-related information generated on a project would hold significant value in executing projects of
a similar nature in the future. Thus the need exists for a mechanism that can be used to capture the
information in a manner suitable for re-use.
(e) An intelligent screening procedure that can be used in retrieving information from archives
A requirement that follows from (d) is a procedure that allows information relevant to the current
project context (i.e. information related to the project’s product, process, organizational/contractual,
and environmental views) to be retrieved from the library in a way that can assist the user in building
up a project risk register.

3. VOCABULARY

One of the challenges in discussing the topics of risk and risk management is the use of a consistent
terminology. As noted previously, a number of 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.
While this approach tends to work in every-day practice, especially where interaction amongst project
participants allows the opportunity to clarify meanings, when attempting to encode risk-related knowledge,
greater precision in the terms used is necessary. We have adopted the following vocabulary, and have
found it helpful, although it is subject to further refinement. (A number of publications address the issue of
risk-related terminology – see for example the Project Management Institute Body of Knowledge (Project
Management Institute 1996), and Risk Analysis and Management for Projects (The Institution of Civil
Engineers and the Faculty and Institute of Actuaries 1998)).

We start with the concept of describing the project context in terms of a number of dimensions or views.
Of particular interest at the outset of a project are four views, these corresponding to the environment in
which the project will be designed, constructed and operated, the physical (product) view of the project
(what is to be constructed and where), the process view of the project (how components of the project will
be designed, procured, constructed and commissioned, when, and in what sequence), and the
organizational/contractual context or view of the project (who is responsible for what). We use the term
“environment” to refer to the physical, regulatory, political, social, financial, and economic context of a
project. The interaction of environmental attributes with a project’s physical, process and organizational
views is a major causative basis for uncertain outcomes in one or more project performance measures.
Each view is comprised of several components, which in turn are described in terms of a set of user-
defined attributes. These attributes are assigned values that reflect the properties of the project under
consideration. The number of attributes and the precision with which values can be assigned to them
change over the course of the project life cycle. Our interest lies with the early phases of a project life
cycle, when decisions are being made as to the feasibility of a project, and how best to procure it.

The term risk issue is used to represent topics or keywords (e.g. short term inflation rate, site conditions,
etc.) of direct relevance to a project, around which uncertainty or a lack of predictability may exist, and
which may result in risk events for one or more views of the project and consequent uncertainty in one or
more project performance measures. Terms used in the literature that correspond to our definition of risk
issue include risk, risk factor, and risk source. A list of risk issues corresponds to the kinds of prompt lists

COF-470-4
presented in the literature (e.g. Perry & Hayes 1985). Leverage can be obtained by classifying risk issues
in a searchable hierarchy, and embedding them in an electronic risk issue library, which is independent of
any particular project type or project context – i.e. a master list of risk issues. Depicted in Figure 1 is a
partial risk issue hierarchy. Work is currently under way to structure as comprehensive a list as possible,
along with semi-automated means to browse it in order to identify issues relevant to the project at hand.
Our risk issue categorization scheme mirrors to a substantial extent our four-view representation of a
project. We treat risk issues as the starting point for assessing causes of uncertainty in project outcomes,
as opposed to effects. For example, a labour shortage would be a risk issue, with a potential effect or
consequence of project delay. Since project delay is an effect that can result from one or more risk
issues, it does not appear in the risk issue hierarchy. The relevance of a risk issue for a project at a given
point in time may be assessed, in some cases, through one or more risk issue drivers. For example,
labour shortage is dependent not only on the uniqueness of the project, but on the general economic
situation in the region where the project is being built. Thus, if the construction industry is at capacity,
labour shortages could be a significant risk issue.

We use the term risk event to correspond to the potential variability in a project parameter (e.g. the
average inflation rate during the construction phase), or one or more scenarios in which the possible
states of nature that can be realized can be identified but which one will occur is not known with certainty
(e.g. a slope failure occurs or not, and if it occurs, how extensive would it be). A risk event can apply to
the project as a whole (e.g. higher than anticipated inflation) – i.e. it is global in its treatment, or it can be
local in terms of its immediate influence and hence treatment (e.g. a slope failure occurs while preparing
the right of way). The distinction between local and global assists in determining how best to incorporate
the risk issue and related risk events in predicting performance of the project. For example, for inflation,
uncertainty is treated through the overall economic model of the project, while for the slope failure
example, it would be treated at the work package level.

Of primary concern is the impact that risk issues have on project performance measures both at the
work package level (in one or more project phases), and on performance at the overall project level.
There is a hierarchy amongst performance measures at both levels. Basic performance measures include
time, cost, (revenue), quality, scope/capacity and safety. It is noted that the last three ultimately get
expressed in terms of time and cost, and these two measures are not independent of one another as they
are a function, in part, of the same variables (e.g. productivity). Integrating over the basic variables at the
work package level results in project level values for time and cost. These in turn feed into global project
performance variables which include measures such as project timelines, cost, capacity, profit, net
present value (NPV), internal rate of return (IRR), debt service coverage ratio (DSCR), and so on. The
existence of risk issues and related risk events with uncertain outcomes result in uncertainty in forecasts
of performance measures at the work package and global levels of a project.

In performing risk analysis of a project, we are interested in predicting the consequences of a risk issue on
project performance, and where it is significant, on developing risk mitigation measures. Risk mitigation
deals with how best to manage a risk using strategies such as redesign, alternative processes
(procurement, construction, etc.), insurance, contingency allowances, contractual language, and so forth.
By linking risk issues through to project performance measures, including consideration of the project
context, it is possible to assess the importance of a risk issue, and judge the efficacy of various risk
mitigation measures.

The linkage between line items in the risk issue hierarchy through to project performance measures is
shown in Figure 2. Ultimately, the effectiveness of the risk management process depends on the need to
exercise judgment and experience as to what risk issues are relevant to the project context at hand, how
to translate applicable risk issues into risk events, and how to quantify the outcomes of these events in
terms of performance measures at the local and global levels of a project.

In summary, a great deal of judgment is involved in identifying and managing risks on a project. In support
of this function, the challenge is to develop a workable schema that is comprehensive in its scope but that
does not bog down project participants in an excruciating level of detail, rendering the process
unworkable. The elements of judgment and pragmatism are integral to the process because of the

COF-470-5
 --01 PROJECT ENVIRONMENT -02 TECHNICAL
-01 Economic -01 Design
-01 General Economic climate -01Technological risk
01 Short tem interest rates 01 Use of unproven technology
02 Long term interest rates -02 Design & design documents
03 Short term inflation rates 01 No standards available
04 Long term inflation rates 02 Change of code
05 Short term exchange rates 03 Inadequate design details
06 Long term exchange rates 04 Poorly coordinated design
07 Taxation changes 05 Errors in design
+02 Inputs 06 Lack of constructibility
+03 Outputs +02 Procurement
+04 Revenue -03 Construction
+02 Financial -01 Site conditions
-03 Natural Environment 01 Site availability
+01 Land elements 02 Lack of site services
+02 Ecological components 03 Unknown U/G utilities
+03 Habitats 04 Access to site
+04 Water 05 Contaminated soil
+05 Air 06 Unusual weather
+06 Archaeological +02 Geotechnical risk
+04 Political +04 Commissioning
-05 Regulatory/Legal +05 Operation & Maintenance
+01 Approval Process -03 ORGANIZATIONAL/CONTRACTUAL
02 Stability of regulatory environment +01 Client
03 Approval for rate changes +02 Design
04 Change in laws +03 Construction
05 Unreasonable enforcement +04 Commissioning
+06 Stakeholder +05 Operation & maintenance
+06 Project team
+07 Contracts
+04 FORCE MAJEURE

Figure 1. Partial Risk Factor Hierarchy

Capacity

R
Time
Risk Issue Environmental I
Hierarchy S Scope Time Cost
K
Physical
E Quality Cost Profit
V
Process E
N Revenue NPV
T Safety
Organizational
S IRR

DSCR

Project context - Effects of risk issue on local project Impact of risk issue on
views performance variables global performance
measures

Figure 2. Hierarchy of Performance Measures

COF-470-6
complex web of interactions that exists between risk issues and project views, along with an inability to
express all of these interactions using a set of definitive quantitative functional relationships.

4. RISK ISSUE LIBRARY AND PROJECT RISK REGISTER

As described previously, we use the concept of a risk issue library to identify a repository of information on
risk issues, risk events, and response measures that is accumulated over time as a particular organization
(government or private sector) undertakes projects. The project risk register, which relates to a specific
project, contains risk issues that arise from a consideration of the various project views (the project
context), and likely values of project view attributes. In building up the project risk register, the user with
the aid of a knowledge-based system would extract risk information that is applicable to the current project
context from the risk issue library and augment it with additional information derived from brainstorming or
from feedback from other experienced project personnel. The project risk register would then serve as the
control document for the risk management function, providing information on risks, their time windows,
methods of incorporating risks into the economic analysis, and appropriate response measures. As the
project progresses the project team would update the register with response measures that were adopted,
the risks that were realized during the project and their impact on project performance measures,
additional risks that might have been identified and so forth. The project risk register would also appraise
the user on possible timelines associated with the risk so that attention can be paid to risks that are likely
to occur in the immediate future. At the end of the project, the information in the register would serve as a
means to augment the organization’s risk issue library knowledge base.

The question then becomes what information should be included in each of the risk issue library and the
project risk register. Identified in Table 1 is our view on what should be contained in each. While still a
work in progress, the contents of Table 1 have been gleaned from an extensive review of the literature,
and from our own experience on conducting risk analyses on actual projects. For each of the entries in
Table 1, we cite brief examples – a global risk issue for the risk issue library, and two local risk issues for
the project risk register. Note again that the risk issue library is project context independent.

As already illustrated in Figure 1, each risk issue has a unique identifier, belongs to a category, and has a
name (e.g. risk issue 01.01.01.03 short term inflation rates under category Economic-Project
Environment). This information stays the same for items selected from the library for inclusion in the
project risk register, and provides for consistency in reporting across projects. The ability to provide a
description of the issue is included (e.g. This issue is relevant if uncertainty exists in inflation rates for one
or more of the inputs (labour, materials, equipment) during the construction phase). As explained
previously, it is useful to note if the risk issue is a local or a global one. For the example at hand, we
would designate it as global, because if present it would affect multiple work packages.

The next four risk issue properties allow the user to specify risk issue drivers for each of the four project
views to assist in the reasoning process as to whether or not this is a risk issue for the project at hand.
Included with these drivers are keywords that correspond to attribute definitions in the project views. This
allows help to be provided to the user in the form of semi-automated browsing of the risk issue library. For
our inflation rate example, drivers for uncertainty in short term inflation rates would include volume of
construction work anticipated in the region during the time period the project is to be constructed, known
shortages of labour, equipment or materials, and so on. A risk event triggered by the risk issue describes
how to express the risk issue for purposes of quantifying the uncertainty around its occurrence and
potential outcome. For the inflation example, commentary provided would be along the following lines: If
the spread in value of the inflation rate is reasonably small, then express the inflation rate in terms of its
first two moments or in the form of a probability density function. If, however, there could be significant
variations in inflation because of different underlying economic scenarios, first represent the event in
terms of 2-3 scenarios (e.g. inflation high, inflation medium, inflation low), assign probabilities to the
different inflation scenarios, and provide an estimate of the outcome of each scenario in the form of a
density function for the inflation rate. The next property treats the primary project performance measures
affected – for our example, work package and total project cost would be affected. This in turn would

COF-470-7
Table 1. Suggested Contents of Risk Issue Library and Project Risk Register
Risk Issue Library – Properties Project Risk Register – Properties
Unique risk issue identifier Unique risk issue identifier
Risk issue name Risk issue name
Risk issue category Risk issue category
Risk issue description Risk issue description
Local or global influence Local or global influence
Risk issue drivers for project environmental view and Environmental elements affected by risk issue
related keywords
Risk issue drivers for project physical view and related Physical elements affected by risk issue
keywords
Risk issue drivers for project process view and related Process elements affected by risk issue
keywords
Risk issue drivers for project organizational/contractual Organizational/contractual attributes affected by risk
view and related keywords issue
Risk event(s) triggered by risk issue For each of the elements in each of the project
views affected, information developed includes:
Primary project performance measures affected: time, Risk event(s) triggered by risk issue, estimates of
cost, capacity, safety, quality likelihoods and outcomes
Methodologies for estimating likelihood and/or Primary project performance measures affected: time,
quantifying impacts of risk event cost, capacity, safety, quality
Methods of incorporating risk event(s) into economic Method used to incorporate risk event(s) into economic
analysis analysis
Links to other risk issues (and whether risk magnified or Quantification of impact of risk event in terms of primary
offset) project performance measures affected
Appropriate risk mitigation measures Links to other risk issues (and whether risk magnified or
offset)
Project views affected by risk mitigation measures Risk mitigation measures adopted
Project stakeholders affected by risk Cost and time impacts of mitigation measures
Project participant(s) most suited to manage risk Quantification of impact of risk event in terms of project
performance measures post mitigation measures
Example scenarios (in form of a template) Project views affected by risk mitigation measures
Project stakeholders affected by risk
Project parties responsible for the risk
Likely time window of risk event
Status of risk as of:
Consequence of risk as of:
Lessons learned

affect other measures such as profit, rate of return, etc. It is possible that a risk issue can impact upon
multiple measures. Methods for estimating the likelihood and/or quantifying impacts of the risk event
suggests how the user may go about assessing probability of occurrence and estimating outcomes (e.g.
use data collected from past projects, retain the services of specialist consultants, conduct field studies,
etc.). Methods of incorporating risk events into the economic analysis include treating directly through
uncertainty measures of existing economic model variables (e.g. inflation rate), through additional work
package items, through additional line items in a given work package, etc. Links to other risk issues deals
with the potential for interaction amongst them. Given the presence of one, does it influence the presence
of another, and in terms of likelihood of occurrence or magnitude of the outcome, are these values
heightened or diminished when risk issues occur together. Assessing the potential for interaction
amongst risk issues is difficult to do, and represents a level of analysis that is seemingly not often pursued
on actual projects. Appropriate risk mitigation strategies attempts to provide advice on ways of handling
the uncertainty caused by the risk issue. Within a finite list of options (e.g. seek more information,
redesign, insure, provide a contingency allowance, etc.), specific actions may be listed. For our inflation
example, this might include use more equipment as opposed to labour intensive processes, use
prefabrication, use an escalation adjusted contract, etc. Depending on the risk mitigation measure
pursued, one or more project views may be affected – redesign might alter the physical view and/or the
process view, etc. Project stakeholders affected identifies the various categories of project participants
that could be affected by the risk event. For the inflation example, the contractor could be affected, the

COF-470-8
project owner could be affected, and end users of the project could be affected. Project participants most
suited to manage the risk identifies the party or parties who are best able to control the risk. For our
inflation example, one could take the position that no party is able to control the risk, and it simply has to
be passed on to the end consumer. However, this may not be possible, so a single or shared assignment
may be made, from the designer in the selection of materials and equipment, to the contractor for the
sequencing of work and methods of construction, to the owner through an escalation adjustment clause.
Finally, the opportunity exists to include little stories in the risk list, citing experience that has been
particularly effective in identifying, quantifying and managing the risk issue.

With respect to entries on the project risk register side, assume that the project scenario being examined
is the development of a high tech park on land currently owned by government. The land has been used
over the last 100 years for a number of industrial processes, and it has housed various kinds of facilities.
Information about past processes is sketchy at best, it is known that the regulatory environment was much
less demanding that it currently is, and as-built drawings related to underground utilities are close to non-
existent. The government wishes to develop the park using a public private partnership, in particular a
FDBOM process (finance, design, build, operate and maintain), where it wishes to restrict its contribution
to the donation of the land, minimize its risk exposure, and bound the lease rate in order to attract high
tech start-ups to the region. The government is currently conducting a combined economic-risk analysis
to determine if the project is a suitable candidate for a P3 arrangement, and how risks should be
allocated. Assume that the environmental, physical and process views of the project have been defined,
using a rather coarse definition. Specifically, the physical view involves the breakdown of the project into
a spatial context, and within that, down into utilities, substructure, and superstructure. Similarly, the
process view treats the construction of work packages for these physical elements. Part of the
environmental view treats the topics of soil and ground water.

The project risk register would then contain risk issue items 02.03.01.03 Unknown underground utilities,
and 02.03.01.05 Contaminated soil (see Figure 1). The information contained in the first five fields for this
entry in the risk register would mirror the information contained in the risk issue library. The next entries
would identify the specific components of the various project views affected by the risk issue, which in this
case would be the soil and water in the environmental view for the physical locations affected, the physical
components affected, including underground services and excavation, and the processes used for
excavation, containment and/or removal of the contaminated soil and location and removal of any
unknown underground utilities. The remainder of the risk register for these two risk issues would be
populated by the definition of risk events (e.g. contaminated soil and/or unknown underground utilities
found in each grid area of the site – yes or no), identification of performance measures affected – e.g. cost
and time, methods used to incorporate risk event into economic analysis (e.g. scenarios of high, medium,
low amount of contaminated soil found in each grid area, probability of occurrence of each scenario, and
with estimate of cost and time consequences for complete handling and remediation), how the risk can be
avoided or reduced (e.g. carrying out more detailed geo-technical studies, incorporation of cost and
duration contingencies into estimates), the effects of the mitigation measures (e.g. increased bid price due
to cost contingencies), post mitigation risk impact, views affected by the mitigation measures (e.g. the
process view in carrying out more detailed geo-technical analysis), stakeholders affected (e.g.
construction personnel likely to be exposed to contaminated soil), parties responsible (e.g. contractor),
and time window of risk event (e.g. initial stages of the construction stage). Other field such as status of
risk can be updated as the project progresses and more information relevant to the risk comes to light.
Allowance for continuous updating of information in this manner is an important consideration in
implementing the risk issue library and the project risk register in electronic form. Additionally, because
populating the system can be a time consuming task, a distinction needs to be drawn between essential
information and discretionary information – i.e. not all fields have to be completed. Further, to the extent
possible, other features such as drop down lists of responses should be made available, along with the
ability to have the user define the contents of these lists. For the project risk register, intelligent reporting
through the use of queries (including keyword searches) and rule-based filtering is a crucial feature, as it
has the potential to provide valuable insights into the clustering of risks in terms of time, space, and
physical components. This can bring to fruition one of the benefits of combining a project risk register with
the four project views described earlier. Additionally, hyperlinks that allow the user to navigate through
related risk information can be provided to enhance the accessibility of the information within the register.

COF-470-9
5. SUMMARY AND CONCLUSIONS

Computer-based structures in the form of a risk issue library independent of any specific project type or
project context, and a project risk register which is reflective of a specific project context as described by
four views – environmental, physical, process, and organizational/contractual have been described. In the
form suggested, they have the potential to improve the risk identification process. Ongoing work is
directed at exploring how the interaction between risks is best handled, at developing as complete a risk
issue library as possible, including a robust classification of risk issues, and at implementing both within a
system that supports all of the views.

6. REFERENCES

Al-Bahar, J.F. and Crandall K.C. (1990) Systematic risk management approach for construction projects.
Journal of Construction Engineering and Management. 116(3), September. 533-546.
Anderson, T. and Madsen, F. (2001) SiteRisk: An IT-Tool for managing Risks at Construction sites.
Safety, Risk and Reliability- Trends in Engineering, Malta.
Crossland, R., McMahon, C.A. and Sims Williams, J.H. (1998) Survey of Current Practice in Managing
Design Risk. University of Bristol, Bristol.
Department of Premier and Cabinet, Tasmania (2002) Project Management. Internet.
http://www.projectmanagement.tas.gov.au/k_base/examples/pagerisk.htm
De Zoysa, S. and Russell, A.D. (2003) Knowledge-based risk identification in infrastructure projects.
Canadian Journal of Civil Engineering. Accepted for publication.
Erikson, C.A. (1979) Risk sharing in construction contracts. Ph.D. thesis. The University of Illinois at
Urbana-Champaign, Urbana, Illinois.
Government of New South Wales (2000) Designing and implementing record keeping systems: Manual
for NSW public offices. Internet.
http://www.records.nsw.gov.au/publicsector/DIRKS/exposure_draft/risk_assessment.htm
Integrated Computer Engineering Inc. (2002) Risk Radar: Essential Software For Managing Project Risk.
Internet. http://www.iceincusa.com/products_tools.htm#Intro
Kangari, R. and Boyer, L.T. (1987) Knowledge based systems and fuzzy sets in risk management.
Microcomputers in Civil Engineering. 2, 273-283.
Leung, H.M., Chuah, K.B. and Rao Tummala, V.M. (1998) A knowledge-based system for identifying
potential project risks. Omega, Vol.26, No.5, 623-638.
Morris, M. and Simm, J. (2000) Construction risk in river and estuary engineering: A guidance manual.
Thomas Telford, London.
Niwa, K. (1989) Knowledge-based risk management in engineering. John Wiley & Sons, New York.
Office of Government Commerce, United Kingdom (2002) Successful Delivery Toolkit. Internet,
http://www.ogc.gov.uk/sdtoolkit/reference/documentation/p15_risklog.html
Patterson, F.D. and Neailey, K. (2002) A risk register database system to aid the management of project
risk. International Journal of Project Management. 20: 365-374.
Perry, J.G. and Hayes, R.W. (1985) Risk and its management in construction projects. Proceedings of the
Institution of Civil Engineers, U.K. 78: 499-521.
Project Management Institute. (1996) A Guide to the Project Management Body of Knowledge.
Simm, J. and Cruickshank, I. (1998) Construction risk in coastal engineering. Thomas Telford, London.
Tah, J.H.M., and Carr, V. (2001) Knowledge-based approach to construction project risk management.
Journal of Computing in Civil Engineering, 15: 170-177.
The Institution of Civil Engineers and the Faculty and Institute of Actuaries. (1998) Risk Analysis and
Management for Projects. London: Thomas Telford.
Ward, S. (1999) Assessing and managing important risks. International Journal of Project Management.
17: 331-336.
Wideman, M.R. (1986) Risk management. Project Management Journal. September, 20-25.
Williams, T.M. (1994) Using a risk register to integrate risk management in project definition. International
Journal of Project Management. 1: 17-22.

COF-470-10