Available online at www.sciencedirect.

com

International Journal of Project Management 29 (2011) 537 – 546

www.elsevier.com/locate/ijproman

Developing risk breakdown structure for information technology

organizations
Vered Holzmann⁎, Israel Spiegler
School of Business Administration, Faculty of Management, Tel Aviv University, Ramat Aviv, Tel-Aviv, 69978, Israel

Received 20 January 2010; received in revised form 3 May 2010; accepted 11 May 2010

Abstract

Any risk management method begins with a preliminary phase of risk identification intended to detect and classify potential risk items. This
paper presents a methodological process for developing a Risk Breakdown Structure (RBS) constructed by analyzing records from previous
projects and past organizational occurrences. An implementation of the method is presented for an Information Technology (IT) organization. The
RBS visually portrays the hierarchical structure of the overall organizational risk pattern, thus facilitating the detection of risk areas that require
special attention from management. The results of an analysis of this IT organization reveals a risk pattern that focuses on customer involvement
and communication issues on the one hand and product description and production requirements on the other hand. The method of analysis
described here utilizes various types of information already existing in an organization and thus should enable managers to structure an appropriate
RBS for their projects.
© 2010 Elsevier Ltd. and IPMA. All rights reserved.

Keywords: Risk management; Risk breakdown structure; Lessons learned; Project management; Content analysis; Clustering

1. Introduction one is related to the manner in which organizations operate, and

Every organization aims to attain competitive advantage to
position itself in the frontier of the business arena. Especially
today, when the business battlefield is usually global, very
dynamic and subject to countless changes, any opportunity to be
better prepared for the future will assist organizations that aim to
attain an advantageous position. However, to be ready for
upcoming events, an organization must create an effective risk
management plan, which starts with accurate and appropriate
risk identification.
The current paper presents a methodological risk identifica-
tion process, demonstrates the implementation of this process in
an IT (Information Technology) organization, and reports the
results of the process in a clear and understandable manner
using a visualized RBS (Risk Breakdown Structure). The study
was developed from the integration of two basic assumptions;
⁎ Corresponding author. Tel.: +972 646 705 5505, +972 544 274568.
E-mail address: veredhz@post.tau.ac.il (V. Holzmann).
0263-7863/$ - see front matter © 2010 Elsevier Ltd. and IPMA. All rights reserved.
doi:10.1016/j.ijproman.2010.05.002
the other is related to the source from which organizational
knowledge can be extracted.
The first premise is that the majority of organizations attempt
to further their interests through the continuous implementation
of a portfolio of projects. Although every project is a different
campaign, organizations are constantly moving toward achiev-
ing their vision by managing a portfolio of projects. Because all
(or at least most) of an organization's past projects were
performed within environments similar to the present environ-
ment, and because they were usually managed and at least
partially carried out by the same teams, it is worthwhile to
embrace a broad approach that takes into account not only the
individual project but also the greater organizational project
portfolio (Turner and Muller, 2003; Callahan and Brooks, 2004;
Shenhar and Dvir, 2007; Dikmen et al., 2008).
The second supposition is that almost every modern
organization possesses an archive that contains a vast amount
of information that can be transposed into valuable management
knowledge. Modern communication technologies enable
538 V. Holzmann, I. Spiegler / International Journal of Project Management 29 (2011) 537–546
people and organizations to create, distribute, receive and store
large quantities of data. There are a number of tools and
techniques that an organization might use to transform its data
into information and further into knowledge. Because an
organization presumably already has this information, no
additional efforts are required for its production (Spiegler,
2003; Lipshitz et al., 2002).
The aim of this study is to construct a valuable and effective
RBS that depicts the actual and relevant risk items in an
arrangement that can be communicated to all project stake-
holders. Therefore, we initiated a process of risk identification
by referring to lessons-learned documents that were generated
during the implementation of an array of projects in the
organization. These lessons-learned documents record descrip-
tion, analysis, and inferences from past experiences in order to
transform the insights for future operations. Each one of the
documents was thoroughly examined, analyzed and assigned a
set of risk codes. The accumulated data were then clustered into
a hierarchical representation of risk factors and events. The
analysis process is generic in nature and can be applied in any
organization, though the results of the process are unique for
each particular organization.
The first part of the paper is a review of the concepts of risk
management and risk identification. It continues by explaining
what an RBS is and how it was applied in other studies. The
second part of the paper describes the implementation of
developing an RBS from lessons-learned documents in an IT
organization. The methodological process integrates qualitative
and quantitative analysis methods. First, content analysis was
conducted to identify potential risk items from records that were
stored in the organization archive. Then, cluster analysis was
implemented to group risk items and to detect important risk
areas. The final part of the paper discusses the attributes of the
revealed risk patterns and presents some concluding remarks.
2. Background
The success of an organization in the modern age in
establishing a position of leadership on the business battlefield
is largely influenced by its ability to predict future states of
affairs and effectively establish a winning strategy to confront
ever-changing circumstances. Though a recent meta-analysis of
the relationship between risk management and IT project
success did not yield conclusive results (De Bakker et al., 2010),
there is a general consensus that effective planning and
implementation of a risk management methodology positively
affects the success rate of any project or process, as has been
described by many studies that have investigated various
industries (e.g., Raz et al., 2002; Cook, 2005; Nalewaik, 2005;
Das and Teng, 1999).
A literature review of project risk management methodolo-
gies reveals several models that represent the course of action
required to manage risk during a project's lifecycle. Each of the
various approaches to risk management is composed of several
phases.
The Guide to Project Management Body Of Knowledge
(PMBOK® Guide), published by the Project Management
Institute (PMI, 2008), describes the knowledge area of project
risk management as the processes that address risk management
planning, identification, analysis, response, and monitoring and
control. Project risk management processes are targeted to
increase the probability and impact of events that are expected
to positively affect the project as well as to decrease the
probability and impact of events that are expected to negatively
affect the project or the achievement of its objectives.
The Software Engineering Institute (SEI) developed a risk
management methodology called Software Risk Evaluation
(SRE) that is specifically targeted toward projects in the
software industry. The SRE paradigm is composed of six
elements. There are five circumferential modules and one
central element. The first module, “identify”, explicitly presents
potential project risks before they become problems. The
second module, “analyze”, involves the conversion of risk data
into information required for decision-making. The third
module, “plan”, represents the procedure for translating risk
information into the decisions and actions that the organization
should take at present and in the future. The next module,
“track”, involves monitoring indicators of project risks and the
actions taken to mitigate risks as planned. The fifth module,
“control”, deals with the correction of deviations from risk plans
and responds to triggering events. The central element,
“communication”, entails information-sharing throughout the
project among the appropriate organizational levels and entities;
this is the key to effective risk management (Williams et al.,
1999; Higuera and Haimes, 1996).
Another risk management method for software projects was
introduced by Boehm (1991). This method is based on two
primary steps, namely, risk assessment and risk control. Each
step was divided into three subsidiary steps. Risk assessment
involves risk identification, risk analysis, and risk prioritization.
Risk control involves risk management planning, risk resolu-
tion, and risk monitoring. For each one of the six steps, Boehm
suggested a list of tools and techniques that could and should be
used by managers to facilitate and improve the risk management
process. The identification tools include checklists, decision-
driver analysis, assumption analysis, and decomposition.
Additional models and methods have been introduced by a
variety of risk management researchers. For example, Chapman
and Ward (2004) presented a very detailed model for risk
management that is composed of nine phases. The nine steps
that compose the risk management process are as follows:
define, focus, identify, structure, ownership, estimate, evaluate,
plan, and manage. Bandyopadhyay et al. (1999) investigated
information technology projects. They identified four levels for
this type of project, including process, application, organiza-
tion, and inter-organization. Corresponding to these four levels
were suggested four major components of risk management,
namely, identification, analysis, reducing measures, and
monitoring. Fairley (1994) discussed risk management proce-
dures in software projects due to the failure to deliver the
required systems within a budget and on schedule. He described
a seven-step risk management process for this type of project
that can be used to increase the probability of project success.
These steps include identifying risk factors, assessing risk
 V. Holzmann, I. Spiegler / International Journal of Project Management 29 (2011) 537–546
probabilities and effects, developing strategies to mitigate
identified risks, monitoring risk factors, invoking a contingency
plan, managing a crisis, and recovering from a crisis.
Surveying an array of risk management models and methods
indicates that there are several core elements that are required
with any method of project risk management. These elements
include the identification of potential risks, the evaluation of
probability and impact, and planning response procedures to
handle these risks if they come into play. The current paper
presents a generic method of identifying risk in project-oriented
organizations. The method is based on the analysis of lessons-
learned documents generated during previous projects. The
output of this identification process is an overall hierarchical
representation of project and organizational potential risks.
3. Risk breakdown structure
There is a variety of tools that can be used to communicate
identified risks to project stakeholders. These tools include the
risk list, risk matrix, risk map and RBS (PMI, 2008; Raz and
Michael, 2001; Macgill and Siu, 2005; Chapman, 2001).
The RBS is a hierarchical structure that represents the overall
project and organizational risk factors and events organized by
group and category. The current paper focuses on the use of
RBS in representing identified risks due to its advantages. The
main advantage of an RBS derives from the ability to display a
comprehensive hierarchical scheme that can be reduced or
broadened, in depth or in breadth, to meet varying needs. The
items in the RBS are exhaustive and mutually exclusive so that
each one of the identified risks can be assigned only to a single
item and cannot be allocated to more than one item. In addition,
the RBS provides a visual illustration of overall risk exposure,
thus enabling the detection of specific risk items, and facilitates
locating risk areas in which the organization is exposed to
severe damage, thus requiring special attention by the
organization management (Hillson, 2002; Hillson, 2003).
There are various approaches to the classification of
identified risks into an RBS. Several approaches propose a
generic concept of risk categorization so that they can be
employed for projects in any business arena. Other approaches
are industry-oriented and offer a predefined list of categories
related to the core business of specific type of projects.
3.1. Generic RBS
A fundamental approach based on the classification of risk
sources into external and internal factors for developing RBS
suggests that external risks are those that originate from areas
beyond the range of organization control, while internal risks
are those that an organization's management can directly
control and influence (Kiser and Cantrell, 2006). Further
segmentation might suggest that external risks are related to
economic, physical, political, and technological features.
Internal risks include local risks related to an individual work
package or category, and global risks that cannot be associated
with any particular work package (Tah and Carr, 2001).
539
An advanced version of this concept is presented by the
Universal Risk Project approach developed by the Risk
Management Specific Interest Group of the Project Manage-
ment Institute (PMI Risk SIG) and the Risk Management
Working Group of the International Council on Systems
Engineering (INCOSE RMWG). This method is designed as a
guidance tool for managers to develop a list of “universal risk
areas” that can be applied to any type of project or operation in
any industry. Although this hierarchical list is not complete or
comprehensive, it provides an overall review of potential risks
that are categorized into three major areas: (1) the management
risk area, which includes risks that can be controlled by the
organization and which are related to various aspects of project
management, system management, and organizational manage-
ment; (2) the external risk area, which represents risks that
originate from factors that are beyond the control of the
organization, such as actions taken by exterior stakeholders, or
climate, demography and market occurrences; and (3) the
technology risk area, which refers to risks that are inherent to
the technology and processes used in the project, product,
system, or analysis (Hall and Hulett, 2002).
An additional RBS scheme was presented by Tchankova
(2002). With this method, the risk sources are displayed in a
hierarchical tree that represents the various environmental areas
in which the risks originated. These include physical, social,
political, operational, economic, legal, and cognitive environ-
ments. Each of the areas is further divided into sub-areas as
specifically required for the purposes of the project or the
organization.
A different approach to the representation of all project risks
is based on project lifecycle. Cohen and Palmer (2004)
suggested classifying any potential risk into one of four stages
in a typical project lifecycle: the feasibility stage, which is the
initial stage of a project; the planning and design stage, in which
the basic parameters for executing the project are established;
the construction stage, which is targeted to actually execute the
work; and the startup and turnover stage, which finalizes the
project. Das and Teng (1999) presented a similar approach
within a strategic alliance process that consists of partner
selection, structuring, operation, and performance evaluation.
3.2. Industry-oriented RBS
Specific formats for RBSs represent a predefined hierarchi-
cal tree composed of branches and leaves, which are developed
based on the core activities related to the type of project that
they were structured for. The construction and engineering
industry benefits from an array of structured RBSs. Tummala
and Burchett (1999) described an RBS for a transmission
construction project that consists of six categories: financial and
economic, political and environmental elements, design, site
construction, physical elements, and “acts of God”. A similar
structure was presented by Dey (2002) for large-scale
construction projects. The identified risk factors include
technical risk, financial risk, economical and political risk,
organizational risk, statutory clearance risk, and “acts of God”.
Miller and Lessard (2001) suggested three major risk categories
540 V. Holzmann, I. Spiegler / International Journal of Project Management 29 (2011) 537–546
for large engineering projects: market-related risk, completion
risk, and institutional risk. Each of these categories was further
divided into sub-categories.
In the software and information technology industry, a well-
known RBS is available for the classification and categorization
of risk in these projects. Taxonomy-Based Risk Identification
describes the processes by which the risk items in each specific
project are identified and categorized into three classes: product
engineering, development environment, and program con-
straints. Each of these classes is further broken down into
elements, which are characterized by attributes. Product
engineering refers to requirements, design, code and unit
tests, integration tests, and engineering specialties. The
development environment class includes the elements of the
development process, the development system, the management
process, management methods and the work environment. The
third class, program constraints, deals with resources, contracts,
and program interfaces. The identification and classification
process is supported by a questionnaire developed by the SEI
called the TBQ-Taxonomy-Based Questionnaire (Carr et al.,
1993; Williams et al., 1999).
In this study, we present a process for structuring an RBS
that is built based on a generic project management method-
ology, though it is adjusted to an organization based on its
projects' history. Instead of using a predefined and structured
hierarchical risk tree and assigning potential risk items to
delineated categories, classes or elements, we develop the RBS
for an organization based on analyzing its previous projects and
the related lessons learned. We suggest constructing the RBS
bottom-up, i.e., collating risk items into risk areas, rather than
the traditional approach of constructing an RBS top-down, i.e.,
assigning risk items to predefined risk areas. The current
method for constructing an RBS is based on gathering concrete,
real, and actual experiences rather than hypothetical scenarios
or potential predicted occurrences.
4. Method
The method of producing an appropriate RBS started with
the collection of a series of project and organizational lessons-
learned documents that describe and analyze past experiences.
Then, two consecutive analysis steps were executed. The first
phase of analysis, which involved qualitative and quantitative
content analysis of lessons-learned documents, was aimed to
assign a set of related risk codes for each document. This step
yielded an organizational risk dataset. The second phase of
analysis, which was based on clustering analysis, generated the
organizational RBS that depicted the hierarchical structure of
risk in this organization.
We implemented the methodological analysis for an
information technology (IT) company. The company is a top
Israeli IT service provider that specializes in end-to-end
solutions in all market sectors and employs over 2500 experts.
Its services include outsourcing, software development, ERP
system applications, payroll and human resource solutions,
technical support and a help-desk.
The data for this study were based on lessons-learned
documents that provide records of previous occurrences and
their analysis. The IT organization granted access to all 40
lessons-learned documents that were generated during 2007. As
a prerequisite for analysis, each document had to be complete
and fulfill the following three conditions: (1) it described in
detail a specific event that occurred either during a project or
during an organizational operation process; (2) it provided all
the relevant information regarding the circumstances of the
event, the stakeholders involved, the unfolding of events, and
the effects on the process or the deliverables; and (3) it
contained an analysis of the situation described as carried out by
the professionals in the organization.
5. Content analysis
The first phase of the study consisted of a thorough content
analysis. Content analysis is a research technique that enables one
to make inferences based on a text while considering the context
in which the text was written and read. The method of content
analysis includes basically two separate, though usually integrat-
ed, approaches, namely, qualitative content analysis and
quantitative content analysis (Krippendorff, 2004; Franzosi,
2004; Neuendorf, 2002). In this study, we utilized both techniques
in an integrated manner, so that the implementation of one method
supported the findings of the other. The qualitative analysis
provided the conceptual framework, while the quantitative
analysis provided measurable terms for the framework.
5.1. Qualitative content analysis
Qualitative content analysis demands meticulously reading
each document, understanding and interpreting the text in its
relevant context, and finally coding and classifying each of the
text units. In the current study, the text units for analysis were the
various collected lessons-learned documents. The coding process
was conducted using a codebook that contained 200 codes, and
was derived from the current body of knowledge in project
management (PMI, 2008; Kerzner, 2006; Barkley and Saylor,
2001; Clealand and Ireland, 2002; Knutson, 2001) and adjusted
utilizing additional data from the body of knowledge in business
process flow (Anupindi et al., 2005; Jeston and Nelis, 2006). In
order to further validate the research codebook and confirm that it
contains references to all potential risk items, two additional
content examinations were carried out. The first was a
classification of the research codebook items into the five project
process groups: initiating, planning, executing, monitoring and
controlling, and closing; and the second was a classification of the
same research codebook items into the nine areas of knowledge:
integration, scope, time, cost, quality, human resource, commu-
nications, risk, and procurement (PMI, 2008). These processes
represent the final stage of a systematic collating procedure that
included the substitution of synonyms followed by replacement of
words and phrases with a common concept, thus producing an
array of distinct meanings representing the units.
The coding process involved three independent professionals
who were employed as coders after a short-term training seminar.
 V. Holzmann, I. Spiegler / International Journal of Project Management 29 (2011) 537–546 541

Each one of the coders had read each one of the lessons-learned
documents and assigned the appropriate set of codes. The results
of their coding were compared for code assignment consistency.
Inconsistencies due to coder error or insufficient code definitions
were detected and corrected iteratively.

5.2. Quantitative content analysis

Quantitative content analysis summarizes the inferences and

insights derived from the preliminary phase to facilitate the
discovery of properties, attributes and patterns that are
embedded in the analyzed text units. The quantitative analysis
results present numerical examinations of the interpreted text Fig. 1. Process group frequency chart.
units and the related categorized codes. The coding process for
the lessons-learned documents from the IT organization resulted
related to risk at the IT company; it was responsible for more
in the assignment of 117 codes out of the 200 codes in the
than half (153 assignments, representing 51%) of the items
research codebook. The other 83 codes were identified as
assigned. A detailed examination of the codes assigned in each
unrelated to the occurrences described in these text units.
one of the process groups identified the subjects of work
Hence, the following quantitative analyses are based on a total
planning and communications planning as the most problematic
of 117 risk codes and their occurrences in the 40 documents.
in the organization. The second most frequent process was
monitoring and controlling, which had 88 code assignments,
5.2.1. Word count
representing 30%. The initiating and executing process groups
The IT organization lessons-learned documents included 40
were each responsible for about 10% of the code assignments to
documents with 36,463 words. However, the list actually
risk codes in this organization. The fifth process group, closing,
contained 4740 distinct terms and concepts. The average lessons-
was not associated with a single code. This can be explained by
learned document had 911 words. The most frequent concepts
the well implemented process of project closing in the
included the following terms: “system” (510 occurrences, 1.40%),
organization or by the timing of conducting the lessons-learned
“customer” (411 occurrences, 1.13%), “accident” (294 occur-
process, which is prior to the final closing of a project.
rences, 0.81%), “procedure” (196 occurrences, 0.54%), and a list of
professionals including managers, engineers and programmers.
5.2.4. Project management knowledge area frequency
A complementary analysis based on code frequency but from
5.2.2. Code frequency
the project management knowledge areas perspective was
The code frequency analysis provided the occurrence rate for
conducted. Each code in the research codebook was ascribed to
concepts, represented by the research codes, in the lessons-
one of the nine project management knowledge areas: integration,
learned text units. The minimum number of codes assigned for
scope, time, cost, quality, human resources, communications,
one document was 9, and the maximum number of codes
risk, and procurement, as presented by the PMBOK® Guide
assigned for one document was 31, with an average of 15.7
(PMI, 2008). The results of the project management knowledge
codes per document.
area frequency analysis as derived from the content analysis of the
The five most frequent items, listed in descending order,
lessons-learned documents appear in Table 1.
which constitute about 15% of the total code assignments, were
The Code Assignments column represents the number of
as follows: (1) define work package responsibilities, (2) define
times that an item from the research codebook was assigned to a
information transfer responsibilities, (3) define work instruc-
tions and constraints, (4) define information transfer require-
Table 1
ments, and (5) distribute information to team members. Code frequency by knowledge area.
Knowledge area Code Documents Codes assigned
5.2.3. Process group frequency assignments assigned
Analysis of the codes assigned to the IT service provider's
No. (%) No. (%) No. (%)
lessons-learned documents, as related to the five project process
groups, yielded the following results. The chart displays the Integration 103 34.45 38 95.00 44 37.61
Scope 83 27.76 34 85.00 32 27.35
number of codes related to each process group and relative
Time 2 0.67 1 2.50 2 1.71
percentages (Fig. 1). Cost 1 0.33 1 2.50 1 0.85
Although only 117 codes were assigned, 299 code assign- Quality 16 5.35 10 25.00 5 4.27
ments were employed in this study because several items of the Human resource 13 4.35 17 42.50 7 5.98
117 codes were assigned to more than one document. Thus, the Communications 39 13.04 29 72.50 12 10.26
Risk management 32 10.70 15 37.50 10 8.55
total number of code assignments exceeds the total number of
Procurement 10 3.34 12 30.00 4 3.42
documents and the total number of research codes. The results
clearly identified the planning process group as the main factor Total 299 100.00 40 117 100.00
542 V. Holzmann, I. Spiegler / International Journal of Project Management 29 (2011) 537–546
document. Thus, this number exceeds the total number of
documents and the total number of research codes. The
Documents Assigned column represents the number of docu-
ments that were assigned to a specific knowledge area. The
percentages for the Documents Assigned were calculated
relative to the total number of documents (40 documents) to
demonstrate the frequency of each knowledge area. The Codes
Assigned column represents the number of codes in each
knowledge area that were assigned to lessons-learned docu-
ments. The percentages for the Codes Assigned were calculated
relative to the total number of codes assigned (117 codes).
The pattern of risk that is revealed by the code frequency
analysis by knowledge areas is characterized by massive impact
within the area of integration and additional significant influence
within the area of scope. Integration received 103 code assign-
ments out of 299 total code assignments, which represented
34.45%. Items related to integration were assigned to 38 out of 40
lessons-learned documents in the company. At the same time, the
integration area was assigned to 44 different items. This suggests
that integration is a widespread topic that is manifested not only in
most of the previous occurrences in the organization but also in
varying items. Scope management manifested in a similar form
because it was assigned to most of the lessons-learned documents
and with a variety of different codes. Communications and risk
management were also identified as influential issues, though less
intensely, and the remaining knowledge areas presented a
relatively flat structure of risk.
6. Clustering
The second phase of analysis in the current study used the
results of the content analysis for clustering. Cluster analysis
was defined by Jain et al. (1999) as “the organization of a
collection of patterns (usually represented as a vector of
measurements, or a point in a multidimensional space) into
clusters based on similarity” (p.265).
Clustering is an advanced statistical method targeted to
represent data, based on measures of proximity between
elements, expressed by maximum distances between groups
and minimal distances within each group. Joining or tree
clustering algorithms, which were used in this study, are
designed to join objects into sequentially larger groups based on
some measure of similarity or distance. The distances represent
a set of rules that function as criteria for grouping or separating
objects, and they can be composed of one or more sets of rules
or conditions (Lorr, 1983; Gelbard et al., 2007).
In this study, we encountered two major motivations for
using cluster analysis. The first reason is that clustering has
predictive power, which is of immense importance for
structuring future possible occurrences. Risk management
deals with anticipating possible future occurrences based on
past experiences. Therefore, the application of cluster analysis
techniques appears to be the most appropriate. The second
reason is that hierarchical trees can be used as useful visualized
communication tools, so that information regarding organiza-
tional risk can be communicated effectively. Because an
effective risk management process requires understanding on
the part of all the stakeholders involved, the development of a
clear visual representation of the potential risk factors and
events as well as the possible impact can be a key contribution.
We explored and compared the results of several clustering
techniques for a single solution of nine clusters: the single
linkage (i.e., nearest neighbor) method, the complete linkage
(i.e., furthest neighbor) method, the average linkage (i.e.,
between groups) method, Ward's method, and the binary-
positive method. Ward's method, which uses the Dice distance
similarity measure and is also known as the Czekanowski or
Sorensen measure, was found to be the most appropriate
technique for the purpose of the current study since it provided a
reasonable representation of the organizational risk tree, as
concluded from discussions with professionals in the organiza-
tion. In Ward's method, calculations are based on the centroid
of each cluster and the square of the likelihood measure of each
case in the cluster to its centroid. Different cases are joined into
one cluster based on minimal variance within a cluster (Jain
et al., 1999; Aldenderfer and Blashfield, 1984; www.statsoft.
com). The method of investigating the variety forms of
similarity available for the clustering stage, and the final
definition of the actual nature of the similarity chosen, required
a firm substantiation. In this study, we limited the assignment of
codes to a single code of any type to a text unit, and we defined
the similarity as the occurrence of a pair of two coded concepts
in a certain document. The density of a couple of risk items was
defined by the repetitive appearance of the couple in the total
array of lessons-learned documents. Thus, the rule for grouping
risk items was based on the level of the repetitive appearance of
these items in the text units. The reasoning for this decision is
imbedded in the notion that a single type of element carries
rarely the sole responsibility for risk occurrences. Hence, it
stands to reason that a pair of occurrences might obtain a much
better ability to reveal the correct picture. It also enabled us to
represent more intense risk areas by multiple risk items, while
less intense risk areas were left to be represented by less risk
items. We analyzed these joint occurrences, identified them and
submitted them as data for the clustering stage.
The visualized representation of the cluster analysis results is
displayed in the following dendrogram chart. It depicts the RBS
of the IT organization as derived from the content analysis of its
lessons-learned documents. The higher levels of the clustering
results are clearly identified in Fig. 2.
The RBS hierarchical representation suggested an interesting
classification of diversified risk items. The highest level of the
hierarchical tree first differentiates between issues of product
description and work required to produce the product on one hand
and customer involvement and communications on the other hand.
Further investigation into the branches that composed these
two major areas revealed the following. The left side of the
dendrogram includes seven branches related to defining and
planning the product and work. The first branch refers to issues of
infrastructure and management support; the second branch
focuses on quality control procedures and analyses; the next
branch refers to the identification of constraints; the following
branch involves change management and risk management; the
fifth branch concentrates on specific resource planning items; the
V. Holzmann, I. Spiegler / International Journal of Project Management 29 (2011) 537–546 543

Fig. 2. Dendrogram representation of risk breakdown structure.

544 V. Holzmann, I. Spiegler / International Journal of Project Management 29 (2011) 537–546
next one relates to accurate definitions of the work required during
the planning phase; and the following branch concerns topics of
product specifications. The right side of the dendrogram is
composed of two branches related to customer involvement and
communications. One of the branches represents the topic of
human resource management and the other one signifies issues of
information exchange among project stakeholders.
The hierarchical risk tree that was constructed by the cluster
analysis provides an overall representation of potential risks. By
locating risk branches that are loaded with various risk items, a
project manager can detect the most severe risk area and prepare
an effective mitigation plan that deals with the expected risks.
Cluster analysis of the data analyzed and categorized during
the content analysis phase provided an organizational RBS.
This hierarchical structure represents project and organizational
potential risks that are pertinent to this specific organization.
The classification of patterns from the content analyzed lessons-
learned documents provided the IT company management with
a useful outline for the preparation of a risk mitigation plan.
7. Discussion
The results of the analyses of the lessons-learned documents
collected from the IT company revealed an extensive array of
risk factors starting from infrastructure and management
support, continuing with the planning of required work,
constraints, human resources and communications, and ending
with change management and quality control. The major
influence of the identified risks was nevertheless related to the
planning phase of communications, which manifested itself in a
later phase as problems with human resource performance.
Interviews with top managers in the IT company, including
the QA manager and the risk management manager, as well as
open discussion forum with project managers in the organiza-
tions confirmed these results. The managers agreed that the
major risk areas in their project were related to human resource
work planning and control and to information exchange among
the various stakeholders. The managers also expressed their
satisfaction from the process of developing an RBS from
available data rather than scanning infinite scenarios and
possibilities.
The pattern of risk that was manifested in the current IT
organization was compatible with the results described in other
studies. For example, Han and Huang (2006) studied 115
software projects and reported on the probability and impact of
six major risk dimensions. These dimensions were users,
requirements, complexity, planning and control, the team, and
the organizational environment. Out of these dimensions, three
were identified as primary factors that contributed to low
performance, namely, the team, requirements, and planning and
control. Another study by Reich (2007) in which 15 project
managers were interviewed, focused on knowledge-based risks
in IT projects. These risks included failure to learn from past
projects, the competence of the project team, problems related
to the transfer of knowledge, the lack of a knowledge map, and
volatility in governance.
Martin and Rice (2007) studied enterprise risks at Dell, HP,
and IBM, three large computer companies. They analyzed
documents using a text analysis software tool called Leximan-
cer. The major identified risk issues for the three computer
companies were related to international economics, customer
demand uncertainties, product and service transitions, manage-
ment control of financial aspects, and relationships with
suppliers. Another study by Drake and Byrd (2006) investigated
risk factors in IT project portfolios. They found that there are
five risk factors: strategic alignment risk, organizational and
management risk, culture and climate risk, project relationship
risk, and financial risk. Though this study examined potential
risks from a broader, organizational point of view, it identified
potential sources of threats that are grounded in behavior and
management rather than in technology.
In summary, the analysis pointed out the human factor as the
major risk driver. This domain is very wide, and it might give
rise to several distinct risks, such as risks related to the exchange
of information, defining subordination and responsibilities,
following instructions, and communicating customers
effectively.
The method to develop an RBS from existing lessons-
learned documents was found to be reliable and able to produce
an accurate representation of potential risks. This type of
method, though implemented differently, was confirmed by
Kutsch and Hall (2010), in a study that stressed the importance
of an in-depth comprehension and an appropriate valuation of
the historical data as a tool to infer risk management plan in IT
projects. The method we presented was perceived by managers
in the IT organization as quite an efficient tool. They preferred
to base their risk analysis process on actual data that was
collected during their previous experiences and stored in the
organization's archive. By doing so, the organization created a
continuous learning process and enriched its global knowledge.
Once there is an established RBS, the risk identification
stage is actually completed, and the project manager can move
to the next stage of developing strategies to mitigate the
identified risks. Based on the output of the analysis presented in
this paper, the project manager has the required information to
make decisions regarding the project risk response planning.
The information that was analyzed during the content analysis
can be further used by the management to produce a response
plan that first detects the most influential risks to be mitigated
and to prioritize them, and then to develop a detailed plan that
identifies the right stakeholder to be responsible for mitigating
each risk, the appropriate strategy to handle the risk, and related
risk items.
8. Conclusions
The concept that risk management is knowledge manage-
ment has been previously presented by Neef (2005). This idea is
implemented in this paper through the construction of an RBS
through the conversion of information that already exists in
organizational documents into a valuable knowledge that can be
used by management to produce an effective risk management
plan. It integrates risk management and knowledge
 V. Holzmann, I. Spiegler / International Journal of Project Management 29 (2011) 537–546
management into one homogeneous method that starts with
existing information and ends with knowledge that emerges as
an RBS, which functions a basis for decisions regarding risk
management plan.
In this study, the integration of qualitative and quantitative
research methods yielded an in-depth understanding of the
project and organizational risk factors and risk events that an
organization might encounter. The qualitative aspect is
supported by content analysis, which is relatively rare in
management science but a well-established research method in
the humanities and social sciences, with extensive applications
in the fields of political science, behavioral sciences, psychol-
ogy and communications. Understanding the text with respect
to its context provides deeper insights regarding the meaning of
the lessons-learned, which is expressed in better categorization.
The categories were then used for quantitative analysis and
clustering. The research method of cluster analysis was used in
this study mainly due to its predictive power, which is of
immense importance in structuring future possible occurrences.
The application of cluster analysis technique appears to be most
appropriate, especially as it has been used by several researchers
in the past, though based on different types of information. For
example, Freeman and Yin (2004) suggested a method to
generate a taxonomy of underlying topics from a set of
unclassified and unstructured documents; Moskovitch et al.
(2006) presented an approach to automating the classification of
clinical guidelines into predefined hierarchical conceptual
categories; and Dey (2002) presented an analytic hierarchy
process and decision tree analysis for a cross-country
construction project based on its work packages.
The method of developing an RBS presented in this study
yielded significant results. However, the assignment of codes was
restricted to a single code of any type to a unit, thus, limiting the
possibility to analyze the implication of the weight or the number
of occurrences of a certain code in a unit. Another imposed
limitation dealt with the decision to refrain from collating the data
derived from the position of an item in relevance to another within
a single document, thus relinquishing the possibility to analyze the
relative impact it might have. Further expending the investigation
of various elements derived from the original documents, in
addition to those investigated in the current study, might improve
the presented method and yield an even better RBS.
References
Aldenderfer, M.S., Blashfield, R.K., 1984. Cluster analysis (Series: Quantitative
Applications in the Social Sciences). Sage Pub, Beverly Hills, CA.
Anupindi, R., Chopra, S., Deshmukh, S.D., Van Mieghem, J.A., Zemel, E.,
2005. Managing business process flows, 2nd ed. Prentice Hall, Upper
Saddle River, NJ.
Bandyopadhyay, K., Mykytyn, P.P., Mykytyn, K., 1999. A framework for
integrated risk management in information technology. Management
Decision 37 (5), 437–444.
Barkley, B.T., Saylor, J.H., 2001. Customer-driven project management.
McGraw-Hill, New York, NY.
Boehm, B.W., 1991. Software risk management: principles and practices. IEEE
Software 8 (1), 32–41.
Callahan, K., Brooks, L., 2004. Essentials of strategic project management.
Wiley, Hoboken, NJ.
545
Carr, M.J., Konda, S.L., Monarch, I., Ulrich, F.C., Walker, C.F., 1993.
Taxonomy-based risk identification, (Technical Report CMU/SEI-93-TR-6,
ESC-TR-93-183). Carnegie Mellon University, Pittsburgh, PA, Software
Engineering Institute.
Chapman, C.B., 2001. The controlling influences on effective risk identification
and assessment for construction design management. International Journal
of Project Management 19 (3), 147–160.
Chapman, C.B., Ward, S.C., 2004. Project risk management: processes,
techniques, and insights 2nd ed. Wiley, Chrichester, West Sussex, England.
Clealand, D.I., Ireland, L.R., 2002. Project management strategic design and
implementation, 4th ed. McGraw-Hill, New York, NY.
Cohen, M.W., Palmer, G.R., 2004. Project risk identification and management.
AACE International Transactions IN11–IN15.
Cook, P., 2005. Formalized risk management: vital tool for project- and
business-success. Cost Engineering 47 (8), 12–13.
Das, T.K., Teng, B.S., 1999. Managing risks in strategic alliances. The
Academy of Management Executive 13 (4), 50–62.
De Bakker, K., Boonstra, A., Wortmann, H., 2010. Does risk management
contribute to IT project success? A met-analysis of empirical evidence.
International Journal of Project Management 28 (5), 493–503.
Dey, P.K., 2002. Project risk management: a combined analytic hierarchy
process and decision tree approach. Cost Engineering 44 (3), 13–26.
Dikmen, I., Birgonul, M.T., Anac, C., Tah, J.H.M., Aouad, G., 2008. Learning
from risks: a tool for post-project risk assessment. Automation in
Construction 18 (1), 42–50.
Drake, J.R., Byrd, T.A., 2006. Risk in information technology project portfolio
management. Journal of Information Technology Theory and Application
8 (3), 1–11.
Fairley, R., 1994. Risk management for software projects. IEEE Software 11 (3),
57–67.
Franzosi, R., 2004. Content analysis. In: Alan, B., Melissa, H. (Eds.), Handbook
of Data Analysis. Sage Pub, Beverly Hills, CA, pp. 547–566.
Freeman, R.T., Yin, H., 2004. Adaptive topological tree structure for document
organization and visualization. Neural Networks 17, 1255–1271.
Gelbard, R., Goldman, O., Spiegler, I., 2007. Investigating diversity of
clustering methods: an empirical comparison. Data & Knowledge
Engineering 63 (1), 155–166.
Hall D.C., Hulett D.T., 2002. Universal Risk Project – Final Report. available at
the PMI Risk SIG website: http://www.risksig.com.
Han, W.M., Huang, S.J., 2006. An empirical analysis of risk components and
performance on software projects. The Journal of Systems and Software 80
(1), 42–50.
Higuera, R.P., Haimes, Y.Y., 1996. Software risk management, Technical
Report. Software Engineering Institute, Carnegie Mellon University,
Pittsburgh, PA.
Hillson, D., 2002. Using the risk breakdown structure (RBS) to understand risks.
Proceedings of the 33rd Annual Project Management Institute Seminars &
Symposium (PMI 2002). 7th–8th October, Philadelphia, PMI, San Antonio,
USA.
Hillson, D., 2003. Using a risk breakdown structure in project management.
Journal of Facilities management 2 (1), 85–97.
Jain, A.K., Murty, M.N., Flynn, P.J., 1999. Data clustering: a review. ACM
Computing Surveys 31 (3), 264–323.
Jeston, J., Nelis, J., 2006. Business process management: practical guidelines to
successful implementations. Butterworth-Heinemann, Jordan Hill, Oxford,
England.
Kerzner, H., 2006. Project management: a system approach to planning,
scheduling, and controlling, 9th ed. John Wiley & Sons, Inc., Hoboken, NJ.
Kiser, J., Cantrell, G., 2006. 6 steps to managing risk. Supply Chain
Management Review 10 (3), 12–17.
Knutson, J., 2001. Project management for business professionals: a
comprehensive guide. John Wiley & Sons, Inc, New York. NY.
Krippendorff, K., 2004. Content analysis: an introduction to its methodology,
2nd ed. Sage Pub, Newbury Park, CA.
Kutsch, E., Hall, M., 2010. Deliberate ignorance in project risk management.
International Journal of Project Management 28 (3), 245–255.
Lipshitz, R., Popper, M., Friedman, V.J., 2002. A multifacet model of organizational
learning. The Journal of Applied Behavioral Science 38 (1), 78–98.
546 V. Holzmann, I. Spiegler / International Journal of Project Management 29 (2011) 537–546
Lorr, M., 1983. Cluster analysis for social scientists. Jossey-Bass Publishers,
San Francisco, CA.
Macgill, S.M., Siu, Y.L., 2005. A new paradigm for risk analysis. Futures 37,
1105–1131.
Martin, N.J., Rice, J.L., 2007. Profiling enterprise risks in large computer
companies using the Leximancer software tool. Risk Management 9, 188–206.
Miller, R., Lessard, D., 2001. Understanding and managing risks in large engineering
projects. International Journal of Project Management 19 (8), 437–443.
Moskovitch, R., Cohen-Kashi, S., Dror, U., Levy, I., Maimon, A., Shahar, Y.,
2006. Multiple hierarchical classifications of free-text clinical guidelines.
Artificial Intelligence in Medicine 37, 177–190.
Nalewaik, A., 2005. Risk management for pharmaceutical project schedules.
AACE International Transactions. Risk 07, 71–75.
Neef, D., 2005. Managing corporate risk through better knowledge manage-
ment. The Learning Organization 12 (2), 112–124.
Neuendorf, K.A., 2002. The content analysis guidebook. Sage Pub, Thousand
Oaks, CA.
PMI (Project Management Institute) Standards Committee, 2008. A guide to the
project management body of knowledge (PMBOK® Guide), 4th ed. Project
Management Institute, Newtown Square, PA.
Raz, T., Michael, E., 2001. Use and benefit of tools for project risk management.
International Journal of Project Management 19 (1), 9–17.
Raz, T., Shenhar, A.J., Dvir, D., 2002. Risk management, project success, and
technological uncertainty. R&D Management 32 (2), 101–110.
Reich, B.H., 2007. Managing knowledge and learning in IT projects: a
conceptual framework and guidelines for practice. Project Management
Journal 38 (2), 5–17.
Shenhar, A.J., Dvir, D., 2007. Reinventing project management: the diamond
approach to successful growth and innovation. Harvard Business School
Press, Boston, MA.
Spiegler, I., 2003. Technology and knowledge: bridging a ‘generating’ gap.
Information & Management 40 (6), 533–539.
Tah, J.H.M., Carr, V., 2001. Towards a framework for project risk knowledge
management in the construction supply chain. Advances in Engineering
Software 32, 835–846.
Tchankova, L., 2002. Risk identification—basic stage in risk management.
Environmental Management and Health 13 (2/3), 290–297.
Tummala, V.M.R., Burchett, J.F., 1999. Applying a risk management process
(RMP) to manage cost risk for an EHV transmission line project.
International Journal of Project Management 17 (4), 223–235.
Turner, J.R., Muller, R., 2003. On the nature of the project as a temporary
organization. International Journal of Project Management 21 (1), 1–8.
Williams, R.C., Pendelios, G.J., Behrens, S.G., 1999. Software Risk Evaluation
(SRE) Method Description (Version 2.0), (Technical Report CMU/SEI-99-
TR-029, ESC-TR-99-029). Software Engineering Institute, Carnegie Mellon
University, Pittsburg, PA.