Journal of Software Engineering and Applications, 2011, 4, 293-305
doi:10.4236/jsea.2011.45032 Published Online May 2011 (http://www.SciRP.org/journal/jsea)
Copyright © 2011 SciRes. JSEA
293
Software Development Project Risk Management:
A New Conceptual Framework
Lazaros Sarigiannidis, Prodromos D. Chatzoglou
Production & Management Engineering Department, Democritus University of Thrace, Xanthi, Greece.
Email: lsarigia@pme.duth.gr
Received March 17th, 2011; revised April 14th, 2011; accepted April 21st, 2011.
ABSTRACT
The frequently observed positive impact of adopting risk management strategies on projects overall outcome has led
many software development organizations to appreciate its significant role in the pursuit of cost reduction, schedule
overruns decrease and, generally, improved performance. In lin e with this issue, this study investigates a wide range of
relevant literature, proposes a new conceptual framework for managing risk in software development projects, intro-
duces new conceptual factors, brings out their interrelation, and suggests new prospects and managerial implications
for both practitioners and academics. The conceptual framework has two basic axes. Firstly, the determination of the
impact of constructs such as Project Characteristics, Project Risk Management Team, Risk Identification Approaches,
and Project Quality on the level of Project Risk. The majority of the items used to measure these constructs are pro-
posed for the first time in the literature. Additionally, the assessment of the impact of Project Risk (and all of the dimen-
sions that compose it), simultaneously with the estimation of the impact of the Residual Performance Risk on the final
subjective and objective Project Performance could provide project managers with a better picture of the effectiveness
and adequacy of their risk management practices.
Keywords: Project Risk, Performance Risk, Project Performance, Software Development, Project Quality
1. Introduction
Risk management has been applied to various fields
like the national security, exploration of space, nuclear
reactors, security, construction industry and financial
investments [1]. This research will focus on the study
of various approaches of risk management applied to
software development projects. Although they have
been applied with success in the last decades, dealing
with problems in the development of various systems,
the fact that a large percentage of the systems is never
completed, or fails to operate effectively and efficiently
[2-11], renders the study of these approaches even
more imperative.
The fact that the majority of the software develop-
ment organisations perceive risk in a different and not
systematic way contributes to the increase of project
development instability and ineffectiveness. Kwak and
Ibbs [12] identified risk management as the least ap-
plied scientific field among the various knowledge ar-
eas of project management. In line with Kwak and Ibbs
study, Adams and Pinto [13] research states that risk
management has not received sufficient attention and
does not appear to be widely accepted within the soft-
ware engineering community. Dedolph [14] implies
that the reason for the software risk management ne-
glection is primarily the organizational inertia and their
native resistance to change, due to the difficulty of risk
management value assessment, the lack of resources,
the need for structural changes and other.
Given the complexity of most software projects and
the several risk types emerged during the develop-
ment/implementation stages, the abandonment of risk
management to human intuition and initiative [15] can
sometimes be proven effective, yet remains an insuffi-
cient substitute of the constant professional and stable
approach of risk management.
Risk management of software development projects
was recognised as an independent field of research in
1989, when Barry W. Boehm lead the way with his
pioneering book “Software Risk Management”. Since
then, this particular issue has been discussed and stud-
ied quite thoroughly, especially in the beginning of ’90s.
The work of Boehm [16,17] and Charette [18,19] laid the
foundations for the extensive contribution of the Soft-
Software Development Project Risk Management: A New Conceptual Framework
294
ware Engineering Institute (SEI) in the middle of ’90s
[20-25], that even today acts as an archetype in several
references in risk management literature.
The goal of the current study is the creation of a new
research model, which emerged from a thorough ex-
amination of the literature, and will be used to measure
various conceptual factors and their relationships in
order to achieve a better and more complete under-
standing of risk management as an organisational
process. In doing so, the effect of several organisa-
tional strategies and characteristics on the determina-
tion of the risk level of software projects, as well as its
consequential influence on the total project perform-
ance, will be assessed. In Sections 2 and 3 the concep-
tual framework and the research questions are pre-
sented, respectively, while some concluding remarks
are provided in Section 4.
2. Literature Review
2.1. Risk Identification Approaches
As Schoenthaler [26] mentioned, based on his practical
experience, it is undeniable that the systematic use of risk
management into the project development process will
have a considerable negative impact on project risks
level. In an attempt to promptly, effectively and easily
identify risk, managers of software projects have been
using various methods. Four of them are going to be dis-
cussed below, in a similar way as they were classified by
Kulik and Weber [27].
The first one is the Ad-hoc Approach, which provides
an assessment of risks when the initial symptoms appear
on the project, as well as their mitigation with unofficial
way. The second approach is called Informal Approach
[28] and includes a discussion with people, who are di-
rectly or indirectly involved with the project, concerning
the several risk issues that appear (or will possibly appear)
and the recording and documentation of the risks for fu-
ture use. The third is named Periodic Approach and, as it
can be understood from its title, involves the use of re-
petitive procedures for the identification and specifica-
tion (quantitatively and qualitatively) of the risks. Finally,
the fourth approach is the Formal Approach for the iden-
tification of the various risks [29]. According to this ap-
proach, a thorough and in-depth assessment of each risk
by independent individuals is performed.
An international research on software development
risk management, carried out in 2001 by the Research
Corporation KLCI, indicated that the most common risk
identification approach is the informal, used by 37% of
the respondents, while Ropponen’s [30] study enforces
the impression of the absence of a framing thinking about
software risk concept and managerial implications by
project managers.
2.2. Project Characteristics
The factors that characterize and, in many occasions,
shape the development process of a project, affect to a
great extend the determination of its risk level. In the
present research, five main characteristics of the software
development projects will be studied.
The first of these is Project Scope, which in this case is
going to be studied through an indicator, Project Dura-
tion [31,32]. This indicator is selected as the measure for
project scope because, as Wallace et al. [32] propose, the
collection of duration information is easy for most pro-
jects and it is suitable to survey-based data collection
procedures.
The second characteristic has to do with whether a
project is carried out totally In-house or in collaboration
with external providers (Outsourcing) [33]. It has been
stressed that outsourcing, as a strategy of gaining com-
petitive advantage for a company, is particularly effec-
tive yet equally risky (due to the complexity and some-
times the vagueness that characterize its procedures)
compared with the in-house method [32,34,35]. Still,
despite the rapid increase of outsourcing in developing
software projects in the past few years (in 2005, 75% of
the USA organizations outsource to some extent), its
effect on the projects’ risk level, and especially on those
taking place in countries with less developed infrastruc-
tures, have been studied poorly by literature [36].
The third characteristic of a software project that will
be examined by this study is its Strategic Orientation
[32,37]. The strategic nature of a system can be measured
by the classification of the projects as 1) strategic, 2)
organizational and 3) informational.
Moreover, Project Diversity constitutes a structural
form that is expressed in work specialization terms [38].
In this research, the project diversity will refer to the dif-
ferentiation level that appears in the knowledge back-
ground, capabilities and experience among the project
development participants [39].
The fifth and final characteristic is the Type of System
being developed [5,40,41]. The failure to identify, under-
stand and confront the risks that are connected to differ-
ent project types is an important and defining factor for
the problems during the realization of the project, con-
cealing the real project risks from their developers (that
is, by differentiating the perceptions that they have
formed for them) [42]. Six main types of software de-
velopment projects can be distinguished [5], in spite of
Glass [3] statement for curious biases and omissions in
Jones’ list: 1) Management Information Systems, which
are the most common software applications, 2) System
Software, like for example the operating systems involv-
Copyright © 2011 SciRes. JSEA
Software Development Project Risk Management: A New Conceptual Framework295
ing software that facilitates software applications (Ap-
plication Software), 3) Commercially-marketed Software,
4) Military Systems, which are created for securing rules
and models in military data, 5) Contract or Outsourced
Software projects in the civilian domain, and 6) End-user
Software projects (software developed by users, not pro-
grammers).
2.3. Risk Dimensions
Barki et al. [43] suggest that the software project risks
consist of interrelated dimensions and their assessment
should not be made with the use of a one-dimension
scale, but, on the contrary, every dimension should be
defined separately, theoretically as well as empirically.
The multidimensional assessment of risk can supply a
clear specification for research and practical purposes
[44].
Despite the significance of studying risk through its
dimensions, very few researches have been carried out on
this issue. McFarlan [45] found three major dimensions
of risk in the software development process: project size,
technology experience and project structure. He sug-
gested, also, that project administrators should develop a
complete and aggregated software risk profile for every
software project. Boehm [17] proposed a software risk
management framework that included the evaluation and
control of risk and conducted a list with the top ten risks
based on his personal professional experience. In spite of
all these, Boehm’s list was lacking some theoretical sub-
stantiation [46] and, moreover, due to its complexity and
other factors that characterize software projects (e.g. in-
visibility, flexibility and conformity) [47], it ceased hav-
ing any diachronic value. Barki et al. [43] conducted a
comprehensive review of studies related to software de-
velopment risk and then they proposed 35 measures for
its estimation. These measures were categorized in five
dimensions: technological newness, application size,
expertise, complexity of the application and organiza-
tional environment. Although this research delivered a
quite useful and understandable instrument for measuring
risk, it was noticed that the risk evaluation scale was ex-
tremely complicated [46,48]. Heemstra and Kusters [49],
based on previous studies and their professional experi-
ence, composed a list of 36 risk variables that were later
grouped into 9 categories. Moynihan [50], in co-opera-
tion with 14 experienced Irish application developers,
evolved a total of 21 points that are risk related. Roppo-
nen and Lyytinen’s [51] questionnaire was relied on
Boehm’s [17] checklist, and distinguish 6 risk compo-
nents based on a survey of project managers including
almost 1100 projects. Furthermore, the Hierarchically
Holographic Modeling framework, introduced by Long-
staff et al. [52], brings out 32 risks in seven dimensions
of systems integration. Houston [53] also proposed a list
of 29 software development risk factors, considering
them as the most important and frequently cited in the
existent literature. Cule et al. [54] categorize risks into
four dimensions according to their source (task, client,
environment, self), which includes 55 software risks, and
they proposed a risk management strategy for each di-
mension. Sumner [55], through structured interviews,
compared the differences of software risks between MIS
and ERP projects and proposed nine risks that are unique
in ERP projects. Kliem [56] developed a list of 38 risks
in BPR (Business Process Reengineering) projects,
which were categorized in 4 main dimensions: people,
management, business and technique. Schmidt et al. [57]
identified 53 risk variables that were categorized in 14
factors and suggested that the difference in the culture of
the three countries (Finland, China and USA) where their
research was carried out, could affect considerably the
list of risks. They finally concluded that only 11 of them
have cross-cultural application. Addison [58] has used
the Delphi technique to collect the opinions of 32 spe-
cialists and then presented a list of 28 risks for e-commerce
projects.
This research will mainly be based on the dimensional
distinction of a quite recent approach, the one proposed
by Wallace et al. [48]. They proposed 27 software de-
velopment risks that could be grouped into six dimen-
sions, those referring to: Users [57,59-61], System Re-
quirements [18,59,62,63], Project Complexity [43,64,65],
Planning and Control [57,59,66,], Team [63,67-69] and
Organizational Environment [5,43,70].
However, in contrast to the Wallace et al. [48] study,
that evaluates only the extent to which each risk state-
ment characterized the projects, and in line with Han and
Huang [59] research, this study will attempt to assess
both the probability of occurrence and the impact for
each risk by the respondents, determining the risk level
of each dimension. In order to calculate the risk exposure
(RE) for each risk item, the formula of Cooper et al. [71]
will be adopted. They propose that the traditional meas-
urement of RE, as the product of possibility and conse-
quence (RE = P*C) [17,28,49,59,72-74,] has significant
disadvantages due to the fact that elements with high
consequence, yet low possibility, can return low risk ex-
posure factors and as so they can be falsely considered as
insignificant. More specifically, they measure the RE
with the following formula: RE = P + C – (P*C) (the
equation works only if the possibility of a risk to occur
and the severity of its impact are in a scale from 0 to 1)
[71]. The adoption of this formula in this study will
hopefully give more stabilized, objective and realistic
data about the significance, and hence the impact, of each
risk dimension on the project.
Copyright © 2011 SciRes. JSEA
Software Development Project Risk Management: A New Conceptual Framework
296
2.4. Project Risk Management Team
Many critical decisions are made by teams rather than by
individuals, because group decisions are more consistent
with rationality than individual ones [75]. In this study,
the concept of the project risk management team will be
also examined. This concept incorporates many diverse
roles, such as the compilation and evaluation of the re-
quired project risk information and its sharing with the
project risk manager, and also requires a detailed under-
standing of the current project risk management method-
ology being used [76]. However, nowadays, most risk
analysis projects are unsuccessful since the internal ex-
perts and subject matter experts are excluded from the
process [77], or there is not sufficient information about
their personal characteristics, abilities and attitude to-
wards risk. Ward [78] underlined this insufficiency and
attempted to trace and theoretically analyze the most
significant characteristics of the project participants who
have taken on the difficult task of risk management.
These characteristics include the Capability and Experi-
ence of the participants, their Motivation for accepting to
undertake initiatives, which importance has been stressed
by Boehm [79], and the Perceived Responsibilities in risk
management. Despite the thorough and analytical theo-
retic foundation of the project risk management team
concept, Ward [78] did not provide a research instrument
for the measurement of this construct. In order to opera-
tionalize this construct, a deductive scale development
approach will be utilized, while the development of the
items will be based on the theoretical definition of the
construct [80].
2.5. Residual Performance Risk
The primary performance influence mechanism of a
software project is a risk called Performance Risk which
represents the difficulty in evaluating the final perform-
ance in terms of cost and schedule overruns [81]. Ac-
cording to Nidumolu [65,81], the estimated performance
risk that is detected in the final development stages of a
project is called Residual Performance Risk. This defini-
tion is used to clearly distinct it from the risk that is
found during other phases in the project’s development
life cycle. Therefore, this risk refers to the difficulty in
assessing the consequences of executing the project,
during the final phase of its development.
Meyer et al. [82] introduced a more “forward think-
ing” approach that emphasizes on the uncertainty frame
of a project. These researchers have agreed that, apart
from the predictable uncertainty that can be controlled by
the traditional methods of risk management, an unex-
pected uncertainty and a general chaos appears in many
innovative projects. As a consequence of this notion of
the project risk profile, the residual performance risk can
be decomposed in two parts, based on the following
equation [36,83]:
Residual Performance Risk = Residual Controllable
Risk + Unforeseeable Risk
The Residual Controllable Risk is expressed by the
uncertainty that continues to exist during the final stages
of the software development projects that can be con-
trolled, and even limited, with various ways. The Un-
foreseeable Risk is the uncertainty that cannot be identi-
fied or controlled while planning the project. However,
despite the intention of previous studies [83] to examine
these two dimensions of residual performance risk sepa-
rately, no effort of this kind is recorded until today in the
international literature. In the present study, a first at-
tempt of disintegrating the factor of residual performance
risk will be made, on the basis of the variables defined by
Na et al. [83, 36] and their classification according to
their notional coherence to the theory.
2.6. Project Performance
The present research will concentrate on the project per-
formance related results since performance is the de-
pendable variable of most vital importance [81].
The performance of a software development project
can be divided, for reasons of better, deeper and more
circumstantial studying, into two main categories: the
subjective and the objective performance [36]. These two
categories used for measuring the performance are quite
important for software developers, and users as well,
since both of them affect directly or indirectly the execu-
tion and implementation of every project [84].
The factor of subjective project performance refers to
the efficiency and efficacy by which a software devel-
opment project is completed (according to the people
involved in the project) [85] and bears in mind two basic
dimensions [72,83,86]: the process performance and the
product performance.
Process Performance is an efficiency measure for the
software development process and can be described by
three dimensions [81]: 1) the increase in the gained
knowledge during the implementation of the project
which is called Learning, 2) the management level in the
development process that is named Control and 3) the
quality of the relationship among the various participants
(managers, technicians, analysts, programmers, external
specialists, users etc.) through the duration of the soft-
ware development process, that is called Quality of In-
teractions [87].
Product Performance is a measure for registering and
illustrating the performance of the final product and is
described by the following three dimensions [65,81]: 1)
the technical performance of the software, that is called
Copyright © 2011 SciRes. JSEA
Software Development Project Risk Management: A New Conceptual Framework
Copyright © 2011 SciRes. JSEA
297
Operational Efficiency, 2) the respond quality to the
needs of the software users, that is noted by the term Re-
sponsiveness and 3) the ability of the software to provide
perceptible support to new products and functions and its
Flexibility to the interchangeable organizational needs.
These two dimensions of project performance need to
be estimated separately since there is not necessarily a
high relationship between them [72]. For example, it is
quite possible that a project with cost or schedule over-
runs problems will deliver a high quality product and
vice versa.
Although the measurement of subjective performance
has the plain advantage of the easy collection of neces-
sary data [36], it deals intensely with the problem of
standardization, since the evaluation of a project depend
on personal judgement or moreover the mood of a certain
manager [84].
Contrary to the subjective performance of a project,
the objective performance includes some more quantified
metrics like, for example, excess in terms of cost, effort
and schedule. According to literature [36,88,89], it is
suggested to measure both subjective and objective pro-
ject performance, due to the special nature that charac-
terizes software development projects.
2.7. Project Quality
Another factor that can significantly define risks, as well
as the level of their presence during the process of a pro-
ject’s software development, is project quality [90,91]. In
the present study, the total quality of a project will be
defined through the measurement of two main factors
and the variables that define them according to literature
[92,93]. These two fundamental factors are: process
quality [94] and people quality. To begin with, people
quality is divided into two main sub-factors, so that it can
be measured with the utmost detail. These two
sub-factors that compose it are management quality and
staff quality.
Management quality includes variables like commu-
nications management adequacy, subcontract manage-
ment adequacy, interaction management adequacy and
internal management quality [95]. On the other hand,
people quality involves the quality of non-administrative
staff that is occupied with a project. For its measurement,
variables like staff turnover, staff experience, staff moti-
vation, staff training and programming language experi-
ence are used [92].
Process quality is a complex factor for defining project
quality; it associates the project specification clarity with
the development and testing process quality. Specifica-
tion clarity is defined by the variables of specification
process quality and requirements difficulty. Development
and testing process quality consists of variables measur-
ing the regularity of reviews, the quality of documenta-
tion and the level of independent testing. In the Age-
naRisk manual of software risk modelling [95] for meas-
uring the development and testing process quality, one
more indicator is used—a model of the maturity of the
capabilities that an organization has in executing specific
organizational procedures, the Capability Maturity Model
(CMM) [96]. In the present research CMM was omitted,
mainly due to the non-categorisation of many companies
worldwide (especially in underdeveloped or developing
countries) to its five levels [47,97].
A summary of the research constructs that compose
the general risk management model is presented in Table
1, along with the number of items that measure them.
What’s more, Figure 1 illustrates the relationships that
exist between them, which will be examined thoroughly
in the following section.
Table 1. Summary of research constructs.
Factors Sub-factors Items References
Strategic
Orientation 3
Project Scope 1
Outsourcing 1
Project Type 3
Project
Characteristics
Project
Diversity 3
[5,31-33,
37-39,98]
Risk Identifica-
tion Ap-
proaches
- 4 [27]
User 5
System
Requirements 4
Project
Complexity 4
Planning and
Control 7
Team 3
Risk Dimen-
sions
Organizational
Environment 4
[5,17,31,40,
43,45,
48-50,52,
54-68,70]
Project Risk
Management
Team
3 [62,78]
Residual
Controllable
Risk
2
Residual
Performance
Risk Unforeseeable
Risk 4
[36,45,65,
81-83,99]
People Quality 10
Project Quality Process
Quality 6 [47,90-96]
Subjective
Performance 24
Project
Performance Objective
Performance 3
[36,48,59,
65,72,81,
83,86,88,
89,97,100]
Software Development Project Risk Management: A New Conceptual Framework
298
Figure 1. Conceptual framework.
3. Conceptual Framework
3.1. The Relationship between Project
Characteristics and Project Risk
In literature, there is a lack of studies that attempt to ex-
amine the various characteristics of software projects and
the way different risk dimensions, especially, and the
total level of risk, in general, are affected by them. This
research will examine, five project characteristics, emerged
from the literature, which have been discussed above
[5,32,38].
First, the development of an application with strategic
orientation has fundamental differences from the devel-
opment of an application for automating various transac-
tions or decision-making. For example, the survey of
Wallace et al. [32] showed that strategic applications
involve more complexity risk than information or trans-
action oriented applications. Yet, though it seems quite
possible that projects of strategic nature differ from
non-strategic projects in terms of risk, far too few em-
pirical researches have been carried out examining the
role various project characteristics play in the appearance
and magnitude of these risks.
Moreover, although the relationship between project
scope and software project risk is known from unpub-
lished experiences, it has not been empirically tested in
depth. However, a research by Huang and Han [46] ele-
vated the fact that a parameter of the project scope, its
duration, affects to a great extent some of the dimensions
of risk, like those of planning and control, team, user and
requirements as well. In total agreement with the survey
of Huang and Han [46], two earlier surveys, those of
Wallace et al. [32] and Zmud [101], verified this parallel
relationship of project scope with risk. Wallace et al. [32]
detected a clear influence of project scope on all risk
dimensions, while Zmud [101] suggested that the higher
level of uncertainty that is observed on projects with long
duration is an outcome of the co-dependence between the
various project procedures and the high level of
co-operation that should be accomplished for the har-
monic and effective management of people, of require-
ments and complexity.
Wallace et al. [32] revealed the insufficiency of sur-
veys about the relationship between the use of outsourc-
ing and project risk, and they verified that the use of
outsourcing would bring a different risk profile compared
to the complete use of intra-organizational resources for
the development of a project. The use of one indicator for
the two different strategies (in-house and outsourcing), in
conjunction with the risk dimensions metrics, can lead to
the exploration and projection of the main sections of a
project that become more or less risky, according to the
selection or not of an outsourcing strategy for their de-
velopment. Through the empirical results of their survey,
Wallace et al. projected the highest levels of risk on the
dimensions of team and planning and control, in those
cases that an organization decides to make use of the
outsourcing strategy. In order to explain this limited rela-
tionship of outsourcing with the total level of risk (as it is
defined by its 6 aforementioned dimensions), they stated
Copyright © 2011 SciRes. JSEA
Software Development Project Risk Management: A New Conceptual Framework299
that projects that are liable to outsourcing practices, justi-
fiably tend to encounter greater challenges and difficul-
ties, in terms of team communication and co-operation,
provided that at least two organizations are engaged.
The issue of project diversity - although it has been a
matter of examination in the field of software develop-
ment many times in the past [38,39,98], concerning its
relation and effect on the degree of success and per-
formance of a project- is obviously absent from the in-
ternational literature, as regards the examination of its
relationship with the risk level of software projects.
Last but not least, Jones [5] defined six basic catego-
ries of software projects and correlated them with the
most risky factors of the project, recognizing that differ-
ent risks affect different software systems with different
weight. Though, the Application Taxonomy catalogue
that Jones presented constitutes an interesting contribu-
tion in the field of risk management, his research suffers
many paradoxical tendencies and omissions that should
be improved through future research. The present study
is going to proceed towards this direction.
The main research question that emerges from the
above discussion, illustrated in Figure 1, is the follow-
ing:
Research Question 1: How the characteristics of a
project affect the level of risk during the development
process?
3.2. The Project Risk Management Team
Relationship with Project Risk
The importance of selecting the appropriate team that
will carry out the risk management process, so as to en-
hance the effectiveness and performance of a project,
was recognized by Ward [78]. Ward expressed the view
that an effective risk management requires from project
development team members to have the necessary moti-
vation, capability and experience, as well as a deep un-
derstanding of their responsibilities both for the process
and the outcome. He also stated that, if one of these re-
quirements (motivation, capability and experience, per-
ceived responsibilities) is missing, or cannot be elevated,
then it will be desired to find a more adequate party for
managing risk. Recognizing the importance of project
participants’ characteristics for the risk management
process, as well as their effect on the total project per-
formance, an attempt will be made to connect these
characteristics with the software development risk. The
examination of this link is another goal of the present
study.
Research Question 2: How the characteristics of the
risk management team affect the level of project devel-
opment risk?
3.3. The Relationship between Project
Characteristics, Project Risk Management
Team and Project Quality
After the analysis of those variables that define some of
the elements that characterize a software project as well
as its stakeholders, and their connection to the project
risk, an attempt will be made to examine their interaction
with project quality. The specific conceptual connection
among these volatile factors, despite its obvious theo-
retical and practical value, has not been studied in depth
in the past, at least not in the restricted framework of
software development. For this reason, the examination
and interpretation of these relationships were considered
essential, despite their indirect reference to the main is-
sue of the emergence, impact, mitigation and overall
management of project risks. No matter what results-con-
clusions will be derived, a wider research framework in the
field of risk management in the international literature
will be hopefully triggered.
Research Question 3: How Project Characteristics
affect Project Quality?
Research Question 4: How Project Risk Management
Team Characteristics affect Project Quality?
3.4. The Relationship of the Risk Identification
Approaches with Project Risk and Project
Performance
Kulik and Weber [27] classified the risk identification
approaches for software projects in four main groups:
ad-hoc, formal, informal and periodic. In the present re-
search a step forward is going to be made, attempting to
connect directly the risk identification approaches with
the level of risk in the software development project and
with the project performance. These relations will be
studied in order to estimate the importance, uniqueness
and effectiveness of every approach on the overall pro-
ject risk assessment (as well as with each risk dimension)
and on project performance, respectively.
Research Question 5: How does the use of different
risk identification approaches on software projects affect
the level of project risk involved?
Research Question 6: How does the use of different
risk identification approaches on software projects affect
project performance?
3.5. The Relationship between Project Quality
and Project Risk
Despite the fact that the quality issue in software devel-
opment project has been taken into consideration in
many research papers in the past (see Section 2.7), none
of these studies investigated its importance and relation-
ship with the conceptual factor of software development
Copyright © 2011 SciRes. JSEA
Software Development Project Risk Management: A New Conceptual Framework
300
risk. In this study, a first attempt will be made to con-
ceptualize this framework using the items suggested by
Fenton’s et al. [92] research for measuring project qual-
ity.
Research Question 7: How does the level of project
quality affect its risk?
3.6. The Relationship of Residual Performance
Risk with Project Performance
Nidumolu [81] was the first to examine the relationship
between project’s residual performance risk and its actual
performance. Data from 64 software development pro-
jects in the USA provided substantial foundation for his
model. Nidumolu used residual performance risk as an
intermediate factor among those of standardization, un-
certainty of requirements and project performance. After
the statistic analysis and the examination of the hypothe-
ses, Nidumolu enunciated the existence of a negative
consequence of residual performance risk on the process
and product performance of the project.
Na et al. [83] attempted to examine the original model
of Nidumolu’s survey in the software development in-
dustry of Korea. By using identical structural models and
by gathering data from Korean software projects that
were developed from 1999 to 2000, they compared the
findings of Nidumolu from the USA with those of their
research. The analysis indicated that the mean of residual
performance risk and its effect on the subjective per-
formance of a project differs significantly between the
two studies and the two countries, since the correlation
coefficients between both residual performance risk and
the two aspects of project performance are not statisti-
cally important for the data of the Korean research. Ac-
cording to Na et al. [83], a possible explanation for this
observed difference is that in technologically developing
countries like Korea, where the systematic use of risk
management is still in early stages, the residual perform-
ance risk is less important and substantial for software
development companies.
Extending the previous research, Na et al. [36] carried
out a survey in three of the largest software development
companies in Korea (companies that occupied at least
25.000 employees). In this survey, Na and his colleagues
attempted to measure (in 123 software development pro-
jects), among others and the relationship between the
residual performance risk and the objective performance
of projects. They reported the existence of a positive and
statistically important relationship between these factors.
A recent study by Jiang et al. [99] measured and
evaluated the effect of the residual performance risk on
the subjective performance of 151 organizations in the
USA This research verified the negative relationship
between these two factors.
Furthermore, since the Korean research [83] was de-
signed to copy the previous American research [81], Na
et al. did not try to collect data that would allow them to
analyse the two elements of residual performance risk.
As a result, they could not define the proportion of the
unforeseeable risk and the residual controllable risk
(through the aforementioned control techniques, at the
final stage, though, of the development of a project), in
the total residual performance risk. For this reason, an-
other contribution of the present study would be the se-
lection of appropriate data that will allow us to study and
analyse thoroughly these two elements of a project’s re-
sidual performance risk. Na et al. [83] stated that since
managers of software projects continue to improve risk
management practices, the mean residual controllable
risk would gradually decrease. However, as the software
development becomes more and more innovative and the
development technology continues to improve rapidly,
the risk of unexpected uncertainty and chaotic situations
could emerge and quickly take gigantic dimensions.
Research Question 8: How does residual performance
risk affect the performance (subjective and objective) of
a project?
Research Question 9: How does unforeseeable risk
and residual controllable risk affect the residual per-
formance risk of a project?
3.7. The Relationship of the Project Risk with
the Project Performance
The relationship between the risk level of a project and
its performance has been examined by several researches
in the past [32,48,59,100]. In particular, Jiang and Klein
[100] agreed that the various risks in software develop-
ment consist a great problem that affects project per-
formance. Wallace et al. [32] composed a model – that
was established in the literature of project management
and the sociotechnical theory, along with the special risk
metrics – that is based on six risk dimensions and ex-
plains to a great extent the variability that occurs on the
project performance. Wallace et al. [48] designed a
model measuring project’s performance and risk level,
and they underlined the reverse relationship between the
two concepts (especially the process instead of the prod-
uct). Recently, Han and Huang [59] examined the rela-
tionship of software risks and their effect on project per-
formance. In their article, they displayed the findings of
an empirical research that was based on 115 software
projects, about the possibility of appearance and the
consequence of the six different dimensions of risks on
project performance.
Considering the above surveys, and since the empirical
data that describe the relationship between risk and pro-
ject performance are rare and often fail to take into con-
Copyright © 2011 SciRes. JSEA
Software Development Project Risk Management: A New Conceptual Framework301
sideration the several risk factors that prevent their suc-
cessful outcome, this study may emerge as a general
framework for future research, so as to investigate the
impact of project risk on both dimensions (subjective and
objective) of performance, and to further examine those
risk factors that are less projected in literature and have
an important effect on project performance.
Research Question 10: How does the level of project
risk affect the performance (subjective and objective) of
a project?
4. Concluding Remarks
In spite of the indisputable fact that in the past 20 years
there have been noticed remarkable efforts internation-
ally (found in literature), it is true that quite enough is-
sues concerning risk management in software develop-
ment projects remain unexamined and lack theoretical
and practical support. The expected goal of this research
is to bridge the gap between the existing literature and
the appropriate practices in the management of software
development projects by evaluating practitioners’ needs
for the successful management of software risks.
Through a brief literature review and the construction
of a new research framework, an explicit conceptual
framework has been formed. In this framework, a group
of factors has been added for the determination of the
total risk level and, moreover, its effect (and all of the
dimensions that compose it) on the final subjective and
objective project performance. The ineffective perform-
ance of many software projects and the consequential
costs and time overruns, missed business prospects, and
the rise of social distrust in the information technologies,
give cause for reflection in the software project man-
agement field; this study will hopefully help in the
evaluation and estimation of several project performance
related aspects.
Part of the value of this framework lies in the concep-
tual representation of factors and the examination of the
possible relationships between them, which have not
received the appropriate attention when thinking about
managing software development projects. While the
value of the risk management has already been under-
lined in the past, and the fact that its theory has made a
lot of advancements, there is no complete model yet de-
scribing and analyzing the relationships between all these
organizational concepts in detail. More specifically,
within the field of software development project risk
management, there is not an extensive, well-grounded,
distinct and applicable system, which will be able to
guide project managers to follow reliable and successful
management mechanisms. The proposed framework is
considered to be an original and complete model that
intends to contribute to literature by exploring the link-
ages among software project risk, risk identification ap-
proaches, project characteristics, project risk manage-
ment team, residual performance risk, project quality and
project performance.
In addition, it must be stressed that another significant
goal of this paper is the recording and examination of
these parameters of risk management in software devel-
opment projects that can induce and motivate managers
or project team members, to a more energetic role in the
risk management practices. This study has provided
many visions of software project risk that project man-
agers should utilize in order to manage the potential risks
related with a particular project and to evaluate effec-
tively the possible alternatives. The multi-dimensional
theoretical background of these practitioners is almost
certain that will provide the necessary spark for the use
of a thorough and systematic approach of risk manage-
ment in the whole project lifecycle (in which risk is as-
sessed in each phase of the project), and to develop the
appropriate risk mitigation strategy in more timely and
scientific way.
Finally, the project risk management issues are not
usually in the agenda of the software development or-
ganizations (and especially at the small ones), because of
the sensitive information that includes and the adherence
to the “shoot the messenger” syndrome, which frequently
discourages the members of the development team from
bringing forthcoming or pending problems to the atten-
tion of management. So, this study may help to get over
this lack of communication between project team mem-
bers (who will find some helpful and practical insights in
the theoretical framework of this research) and, mainly,
by changing and integrating a new effectual culture con-
sidering the risks that their projects face.
The research model suggested here has to be validated
using real life data. Authors have already constructed a
structured questionnaire which has been refined in sev-
eral pre-test stages and interviews with academics and
practitioners (project managers and programmers) ex-
perts in software project development. The data collec-
tion process will commence by the end of January, 2011,
while the first results are expected by the end of March,
2011.
REFERENCES
[1] J. H. Iversen, L. Mathiassen and P. A. Nielsen, “Manag-
ing Risk in Software Process Improvement: An Action
Research Approach,” MIS Quarterly, Vol. 28, No. 3,
2004, pp. 395-433.
[2] W. W. Gibbs, “Softwares Chronic Crisis,” Scientific A mer i-
can, Vol. 271, No. 3, 1994, pp. 86-95.
doi:10.1038/scientificamerican0994-86
[3] R. Glass, “Software Runaways—Some Surprising Find-
Copyright © 2011 SciRes. JSEA
Software Development Project Risk Management: A New Conceptual Framework
302
ings,” The DATABASE for Advances in Information Sys-
tems, Vol. 28, No. 3, 1997, pp. 16-19.
[4] J. Johnson, “My Life is Failure: 100 Things You Should
Know to Be a Successful Project Leader,” Standish
Group International, West Yarmouth, 2006.
[5] C. Jones, “Assessment and Control of Software Risks,”
Yourdon Press, Englewood Cliffs, 1994.
[6] C. Jones, “Risks of Software System Failure or Disaster,”
American Progr a mmer, Vol. 8, No. 3, 1995, pp. 2-9.
[7] G. Klein and J. J. Jiang, “Seeking Consonance in Infor-
mation Systems,” Journal of Systems and Software, Vol.
56, No. 2, 2001, pp. 195-202.
doi:10.1016/S0164-1212(00)00097-2
[8] K. Lyytinen and R. Hirschheim, “Information Systems
Failures—A Survey and Classification of the Empirical
Literature,” Oxford Surveys in Information Technology,
Vol. 4, No. 1, 1987, pp. 257-309.
[9] J. McManus, “Risk Management in Software Develop-
ment Projects,” Elsevier Butterworth-Heinemann, Am-
sterdam, 2004.
[10] J. Ropponen and K. Lyytinen, “Can Software Risk Man-
agement Improve System Development: An Exploratory
Study,” European Journal of Information Systems, Vol. 6,
No. 1, 1997, pp. 41-50.
doi:10.1057/palgrave.ejis.3000253
[11] D. Shafer, “Software Risk: Why Must We Keep Learning
from Experience?” Dynamic Positioning Conference,
Houston, 28- 30 September 2004, pp. 1-19.
[12] Y. H. Kwak and C. W. Ibbs, “Calculating Project Man-
agements Return on Investment,” Project Management
Journal, Vol. 31, No. 2, 2000, pp. 38-47.
[13] K. M. Adams and C. A. Pinto, “Software Development
Project Risk Management: A Literature Review,” Pro-
ceedings of the 26th National Conference, Organizational
Transformation: Opportunities and Challenges, American
Society for Engineering Management, Rolla, October
2005, pp. 635-641.
[14] F. M. Dedolph, “The Neglected Management Activity:
Software Risk Management,” Bell Labs Technical Jour-
nal, Vol. 8, No. 3, 2003, pp. 91-95.
doi:10.1002/bltj.10077
[15] J. Kontio, G. Getto and D. Landes, “Experiences in Im-
proving Risk Management Processes Using the Concepts
of the Riskit Method,” Proceedings of the ACM SIGSOFT
6th International Symposium on Foundations of Software
Engineering, ACM Press, New York, November 1998, pp.
163-174.
[16] B. W. Boehm, “Software Risk Management,” IEEE Press,
Piscataway, 1989.
[17] B. W. Boehm, “Software Risk Management: Principles
and Practices,” IEEE Software, Vol. 8, No. 1, 1991, pp.
32-41. doi:10.1109/52.62930
[18] R. N. Charette, “Software Engineering Risk Analysis and
Management,” Intertext Publications, New York, 1989.
[19] R. N. Charette, “Applications Strategies for Risk Analy-
sis,” McGraw-Hill, New York, 1990.
[20] M. J. Carr, S. L. Konda, I. Monarch, F. C. Ulrich and C. F.
Walker, “Taxonomy-Based Risk Identification,” SEI Re-
port CMU/SEI-93-TR-6, Carnegie Mellon University,
Pittsburgh PA, 1993.
[21] A. J. Dorofee, J. A. Walker, C. J. Alberts, R. P. Higuera,
R. L. Murphy and R. C. Williams, “Continuous Risk
Management Guidebook,” Carnegie Mellon University,
Pittsburgh, 1996.
[22] R. P. Higuera, D. P. Gluch, A. J. Dorofee, R. L. Murphy,
J. A. Walker and R. C. Williams, “An Introduction to
Team Risk Management,” SEI Report CMU/SEI-94-SR-01,
Carnegie Mellon University, Pittsburgh, 1994.
[23] R. P. Higuera and Y. Y. Haimes, “Software Risk Mana-
gement,” SEI Report CMU/SEI-96-TR-012, Carnegie
Mellon University, Pittsburgh PA, 1996.
[24] F. J. Sisti and S. Joseph, “Software Risk Evaluation
Method,” SEI Report CMU/SEI-94-TR-19, Carnegie
Mellon University, Pittsburgh PA, 1994.
[25] R. L. van Scoy, “Software Development Risk: Opportunity,
Not Problem,” SEI Report CMU/SEI-92-TR-30, Carnegie
Mellon University, Pittsburgh PA, 1992.
[26] F. Schoenthaler, “Risk Management in Challenging Busi-
ness Software Projects,” Proceedings of the 10th Anniver-
sary IEEE Joint International Conference on Requirements
Engineering, Essen, Germany, 9-13 September 2002, pp.
1-3.
[27] P. Kulik and K. Weber, “Software Risk Management
Practices—2001,” KLCI Research Group, Dayton, 2001.
[28] S. Ward, “Assessing and Managing Important Risks,”
International Journal of Project Management, Vol. 17,
No. 6, 1999, pp. 331-336.
doi:10.1016/S0263-7863(98)00051-9
[29] K. Wiegers, “Know Your Enemy: Software Risk Man-
agement,” Software Development, Vol. 6, No. 10, 1998,
pp. 38-42.
[30] J. Ropponen, “Software Risk Management—Foundations,
Principles and Empirical Findings,” Jyvaskyla University
Printing House, Jyvaskyla, 1999.
[31] S. Murthi, “Preventive Risk Management for Software
Projects,” IT Professional, Vol. 4, No. 5, 2002, pp. 9-15.
doi:10.1109/MITP.2002.1041172
[32] L. Wallace, M. Keil and A. Rai, “Understanding Software
Project Risk: A Cluster Analysis,” Journal of Information
and Management, Vol. 42, No. 1, 2004, pp. 115-125.
[33] R. Hirschheim and M. Lacity, “The Myths and Realities
of Information Technology Insourcing,” Communications
of the ACM, Vol. 43, No. 2, 2000, pp. 99-107.
doi:10.1145/328236.328112
[34] P. D. Chatzoglou and L. Sarigiannidis, “Business Out-
sourcing and Organisational Performance: The Case of
the Greek Hotel Industry,” International Journal of Ser-
vices Technology and Management, Vol. 11, No. 2, 2009,
pp. 105-127. doi:10.1504/IJSTM.2009.022520
[35] R. T. Nakatsu and C. L. Iacovou, “A Comparative Study
of Important Risk Factors Involved in Offshore and Do-
mestic Outsourcing of Software Development Projects: A
Copyright © 2011 SciRes. JSEA
Software Development Project Risk Management: A New Conceptual Framework303
Two-Panel Delphi Study,” Information and Management,
Vol. 46, No. 12, 2009, pp. 57-68.
doi:10.1016/j.im.2008.11.005
[36] K. S. Na, J. T. Simpson, X. Li, T. Singh and K. Y. Kim,
“Software Development Risk and Project Performance
Measurement: Evidence in Korea,” The Journal of Sys-
tems and Software, Vol. 80, No. 1, 2007, pp. 596-605.
doi:10.1016/j.jss.2006.06.018
[37] E. Clemons, “Evaluation of Strategic Investments in In-
formation Technology,” Communications of the ACM,
Vol. 34, No. 1, 1991, pp. 22-36.
doi:10.1145/99977.99985
[38] A. M. Aladwani, “IT Project Uncertainty, Planning and
Success: An Empirical Investigation from Kuwait,” In-
formation Technology and People, Vol. 15, No. 3, 2002,
pp. 210-226.
[39] M. A. Campion, G. J. Medsker and A. C. Higgs, “Rela-
tions between Work Group Characteristics and Effec-
tiveness: Implications for Designing Effective Work
Groups,” Personnel Psychology, Vol. 46, No. 4, 1993, pp.
823-850. doi:10.1111/j.1744-6570.1993.tb01571.x
[40] D. Houston, G. Mackulak and J. Collofello, “Stochastic
Simulation of Risk Factor Potential Effects for Software
Development Risk Management,” Journal of Systems and
Software, Vol. 59, No. 3, 2001, pp. 247-257.
doi:10.1016/S0164-1212(01)00066-8
[41] C. Jones, “Software Assessments, Benchmarks, and Best
Practices,” Addison-Wesley, Boston MA, 2000.
[42] D. Gotterbarn and S. Rogerson, “Responsible Risk
Analysis for Software Development: Creating the Soft-
ware Development Impact Statement,” Communications of
the Association for Information Systems, Vol. 15, 2005,
pp. 730-750.
[43] H. Barki, S. Rivard and J. Talbot, “Toward an Assess-
ment of Software Development Risk,” Journal of Man-
agement Information Systems, Vol. 10, No. 2, 1993, pp.
203-225.
[44] M. Boban, Z. Pozgaj and H. Seric, “Strategies for Suc-
cessful Software Development Risk Management,” Man-
agement, Vol. 8, 2003, pp. 77-91.
[45] F. W. McFarlan, “Portfolio Approach to Information
Systems,” Harvard Business Review, Vol. 59, No. 5,
1981, pp. 142-150.
[46] S. J. Huang and W. M. Han, “Exploring the Relationship
between Software Project Duration and Risk Exposure: A
Cluster Analysis,” Journal of Information and Manage-
ment, Vol. 45, No. 3, 2008, pp. 175-182.
[47] B. Hughes and M. Cotterell, “Software Project Mana-
gement,” 4th Edition, McGraw-Hill, New York, 2006.
[48] L. Wallace, M. Keil and A. Rai, “How Software Project
Risk Affects Project Performance: An Investigation of the
Dimensions of Risk and an Exploratory Model,” Decision
Sciences, Vol. 35, No. 2, 2004, pp. 289-321.
doi:10.1111/j.00117315.2004.02059.x
[49] F. J. Heemstra and R. J. Kusters, “Dealing with Risk: A
Practical Approach,” Journal of Information Technology,
Vol. 11, No. 4, 1996, pp. 333-346. doi:10.1057/jit.1996.7
[50] T. Moynihan, “How Experienced Project Managers As-
sess Risk,” IEEE Software, Vol. 14, No. 3, 1997, pp.
35-41. doi:10.1109/52.589229
[51] J. Ropponen and K. Lyytinen, “Components of Software
Development Risk: How to Address Them? A Project
Manager Survey,” IEEE Transactions on Software Engi-
neering, Vol. 26, No. 2, 2000, pp. 98-112.
doi:10.1109/32.841112
[52] T. A. Longstaff, C. Chittister, R. Pethia and Y. Y. Haimes,
“Are We Forgetting the Risks of Information Technol-
ogy?” IEEE Computer, Vol. 33, No. 12, 2000, pp. 43-51.
[53] D. Houston, “A Software Project Simulation Model for
Risk Management,” Ph.D. Thesis, Arizona State Uni-
versity, Tempe AZ, 2000.
[54] P. Cule, R. Schmidt, K. Lyytinen and M. Keil, “Strategies
for Heading off Project Failure,” Information Systems
Management, Vol. 17, No. 2, 2000, pp. 65-73.
doi:10.1201/1078/43191.17.2.20000301/31229.8
[55] M. Sumner, “Risk Factors in Enterprise Wide/ERP Pro-
jects,” Journal of Information Technology, Vol. 15, No. 4,
2000, pp. 317-327.
doi:10.1080/02683960010009079
[56] R. Kliem, “Risk Management for Business Process Reen-
Gineering Projects,” Information Systems Management,
Vol. 17, No. 4, 2001, pp. 71-73.
[57] R. Schmidt, K. Lyytinen, M. Keil and P. Cule, “Identify-
ing Software Project Risks: An International Delphi
Study,” Journal of Management Information Systems,
Vol. 17, No. 4, 2001, pp. 5-36.
[58] T. Addison, “E-Commerce Project Development Risks:
Evidence from a Delphi Survey,” International Journal of
Information Management, Vol. 23, No. 1, 2003, pp. 25-40.
doi:10.1016/S0268-4012(02)00066-X
[59] W. M. Han and S. J. Huang, “An Empirical Analysis of
Risk Components and Performance on Software Pro-
jects,” The Journal of Systems and Software, Vol. 80, No.
1, 2007, pp. 42-50. doi:10.1016/j.jss.2006.04.030
[60] J. Jiang and G. Klein, “Risks to Different Aspects of Sys-
Tem Success,” Information and Management, Vol. 36,
No. 5, 1999, pp. 264-272.
doi:10.1016/S0378-7206(99)00024-5
[61] S. Sakhtevil, “Managing Risks in Offshore Systems De-
velopment,” Communications, Vol. 50, No. 4, 2007, pp.
69-75.
[62] B. Curtis, S. Ward and C. Chapman, “Roles, Responsibili-
ties and Risks in Management Contracting,” Construction
Industry Research and Information Association (CIRIA)
Special Publication 81, 1991.
[63] O. Mizuno, T. Kikuno, Y. Takagi and K. Sakamoto,
“Characterization of Risky Projects Based on Project
Managers Evaluation,” Proceedings of the 22nd Inter-
National Conference on Software Engineering, Limerick,
4-11 June 2000, pp. 387-395.
[64] C. F. Kemerer and G. L. Sosa, “Systems Development
Risks in Strategic Information Systems,” Information and
Copyright © 2011 SciRes. JSEA
Software Development Project Risk Management: A New Conceptual Framework
304
Software Technology, Vol. 33, No. 3, 1991, pp. 212-223.
doi:10.1016/0950-5849(91)90136-Y
[65] S. R. Nidumolu, “The Effect of Coordination and Uncer-
tainty on Software Project Performance: Residual Per-
formance Risk as an Intervening Variable,” Information
Systems Research, Vol. 6, No. 3, 1995, pp. 191-219.
doi:10.1287/isre.6.3.191
[66] S. P. Keider, “Why Systems Development Projects Fail,”
Journal of Information Systems Management, Vol. 1, No.
3, 1984, pp. 33-38. doi:10.1080/07399019408963043
[67] T. K. Abdel-Hamid, “A Study of Staff Turnover, Acqui-
sition, and Assimilation and Their Impact on Software
Development Cost and Schedule,” Journal of Manage-
ment Information Systems, Vol. 6, No. 1, 1989, pp. 21-39.
[68] F. P. Brooks, “No Silver Bullet: Essence and Accidents of
Software Engineering,” Computer, Vol. 22, No. 4, 1987,
pp. 10-19. doi:10.1109/MC.1987.1663532
[69] J. J. Jiang, G. Klein and T. Means, “Project Risk Impact
on Software Development Team Performance,” Project
Management Journal, Vol. 31, No. 4, 2000, pp. 19-26.
[70] S. L. Jarvenpaa and B. Ives, “Executive Involvement and
Participation in the Management of Information Tech-
nology,” MIS Quarterly, Vol. 15, No. 2, 1991, pp.
205-277. doi:10.2307/249382
[71] D. F. Cooper, S. Grey, G. Raymond and P. Walker, “Pro-
ject Risk Management Guidelines: Managing Risk in
Large Projects and Complex Procurements,” John Wiley
and Sons Ltd., Chichester, 2005.
[72] H. Barki, S. Rivard and J. Talbot, “An Integrative Con-
tingency Model of Software Project Risk Management,”
Journal of Management Information Systems, Vol. 17, No.
4, 2001, pp. 37-69.
[73] K. Padayachee, “An Interpretive Study of Software Risk
Management Perspectives,” Proceedings of the 2002 An-
nual Research Conference of the South African Institute of
Computer Scientists and Information Technologists on
Enablement Through Technology, Bela Bela, 2002, pp.
118-127.
[74] S. L. Pfleeger, “Risky Business: What We Have Yet to
Learn about Software Risk Management,” Journal of
Systems and Software, Vol. 53, No. 3, 2000, pp. 265-273.
doi:10.1016/S0164-1212(00)00017-0
[75] B. Rockenbach, A. Sadrieh and B. Mathauschek, “Teams
Take the Better Risks,” Journal of Economic Behavior
and Organization, Vol. 63, No. 3, 2007, pp. 412-422.
doi:10.1016/j.jebo.2005.04.023
[76] L. Labuschagne, “Project Risk Management Roles and
Responsibilities,” 2010.
http://www.zulanas.lt/images/adm_source/docs/2_full%20
paperENG.pdf
[77] T. R. Peltier, “Risk Analysis and Risk Management,”
Information Systems Security, Vol. 13, No. 4, 2004, pp.
44-56. doi:10.1201/1086/44640.13.4.20040901/83732.7
[78] S. Ward, “Requirements for an Effective Project Risk
Management Process,” Project Management Journal, Vol.
30, No. 3, 1999, pp. 37-43.
[79] B. W. Boehm and R. Ross, “Theory-W Software Project
Management: Principles and Examples,” IEEE Transac-
tions on Software Engineering, Vol. 15, No. 7, 1989, pp.
902-916. doi:10.1109/32.29489
[80] T. R. Hinkin, “A Review of Scale Development Practices
in the Study of Organization”, Journal of Management,
Vol. 21, No. 5, 1995, pp. 967-988.
doi:10.1177/014920639502100509
[81] S. R. Nidumolu, “Standardization, Requirements Uncer-
tainty and Software Project Performance,” Information
and Management, Vol. 31, No. 3, 1996, pp. 135-150.
doi:10.1016/S0378-7206(96)01073-7
[82] A. Meyer, C. Loch and M. Pich, “Managing Project Un-
certainty: From Variation to Chaos,” Sloan Management
Review, Vol. 43, No. 2, 2002, pp. 60-67.
[83] K. S. Na, X. Li, J. T. Simpson and K. Y. Kim, “Uncer-
tainty Profile and Software Project Performance: A
Cross-National Comparison,” The Journal of Systems and
Software, Vol. 70, No. 1-2, 2004, pp. 155-163.
doi:10.1016/S0164-1212(03)00014-1
[84] T. Singh, “Software Development Risk Management in
Information Technology Developing Countries: An As-
sessment on Subjective and Objective Performance,”
Thesis, University of Alabama in Huntsville, Huntsville,
2005.
[85] C. Wohlin, A. V. Mayrhauser, M. Host and B. Regnell,
“Subjective Evaluation as a Tool for Learning from
Software Project Success,” Information and Software
Technology, Vol. 42, No. 1, 2000, pp. 983-992.
doi:10.1016/S0950-5849(00)00150-6
[86] A. Rai and H. Al-Hindi, “The Effects of Development
Process Modelling and Task Uncertainty on Development
Quality Performance,” Information and Management, Vol.
37, No. 6, 2000, pp. 335-346.
doi:10.1016/S0378-7206(00)00047-1
[87] J. Miller and B. A. Doyle, “Measuring the Effectiveness
of Computer-Based Information Systems in the Financial
Services Sector,” MIS Quarterly, Vol. 11, No. 1, 1987, pp.
107-124. doi:10.2307/248832
[88] L. C. Briand, K. E. Emam and F. Bomarius, “COBRA: A
Hybrid Method for Software Cost Estimation, Bench-
Marking, and Risk Assessment,” Proceedings IEEE In-
ternational Conference on Software Engineering, Kyoto,
19-25 April, 1998, pp. 390-399.
[89] A. R. Gray, S. G. MacDonell and M. J. Shepperd, “Fac-
tors Systematically Associated with Errors in Subjective
Estimates of Software Development Effort: The Stability
of Expert Judgement,” 6th IEEE International Symposium
on Software Metrics, Boca Raton, 4-6 November, 1999,
pp. 216-227.
[90] J. Herbsleb, D. Zubrow, D. Goldenson, W. Hayes and M.
Paulk, “Software Quality and the Capability Maturity
Model,” Communications of the ACM, Vol. 40, No. 6,
1997, pp. 30-40. doi:10.1145/255656.255692
[91] M. Ould, “Managing Software Quality and Business
Risk,” Wiley, Chichester, 1999.
Copyright © 2011 SciRes. JSEA
Software Development Project Risk Management: A New Conceptual Framework
Copyright © 2011 SciRes. JSEA
305
[92] N. Fenton, W. Marsh, M. Neil, P. Cates, S. Forey and M.
Tailor, “Making Resource Decisions for Software Pro-
jects,” Proceedings of the 26th International Conference
on Software Engineering, Edinburgh, 23-28 May 2004,
pp. 397-406. doi:10.1109/ICSE.2004.1317462
[93] N. Fenton, M. Neil, W. Marsh, P. Hearty, L. Radliński
and P. Krause, “On the Effectiveness of Early Life Cycle
Defect Prediction with Bayesian Nets,” Empirical Soft-
ware Engineering, Vol. 13, No. 5, 2008, pp. 499-537.
doi:10.1007/s10664-008-9072-x
[94] G. Hoffman, “Integrating PSP and CMMI Level 5,” STC
Proceedings, 2003.
http://www.stc-online.org/stc2003proceedings/PDFFiles/
pres1001.pdf
[95] AgenaRisk, “Software Project Risk Model Manual.
Bayesian Network and Simulation Software for Risk
Analysis and Decision Support-AgenaRisk (Version 2.00),”
2005. http://www.agenarisk.com/
[96] G. H. Subramanian, J. J. Jiang and G. Klein, “Software
Quality and IS Project Performance Improvements from
Software Development Process Maturity and IS Imple-
mentation Strategies,” Journal of Systems and Software,
Vol. 80, No. 4, 2007, pp. 616-627.
doi:10.1016/j.jss.2006.06.014
[97] M. Keil, L. Wallace, D. Turk, G. Dixon-Randall and U.
Nulden, “An Investigation of Risk Perception and Risk
Propensity on the Decision to Continue a Software De-
velopment Project,” The Journal of Systems and Software,
Vol. 53, No. 2, 2000, pp. 145-157.
doi:10.1016/S0164-1212(00)00010-8
[98] P. J. Guinan, J. G. Cooprider and S. Faraj, “Enabling
Software Development Team Performance during Re-
quirements Definition: A Behavioral Versus Technical
Approach,” Information Syste ms Research, Vol. 9, No. 2,
1998, pp. 101-125. doi:10.1287/isre.9.2.101
[99] J. J. Jiang, G. Klein, S. P. J. Wu and T. P. Liang, “The
Relation of Requirements Uncertainty and Stakeholder
Perception Gaps to Project Management Performance,”
The Journal of Systems and Software, Vol. 82, No. 5,
2009, pp. 801-808. doi:10.1016/j.jss.2008.11.833
[100] J. J. Jiang and G. Klein, “Software Development Risks to
Project Effectiveness,” The Journal of Systems and Soft-
ware, Vol. 52, No. 1, 2000, pp. 3-10.
doi:10.1016/S0164-1212(99)00128-4
[101] R. W. Zmud, “Management of Large Software Develop-
ment Efforts,” MIS Quarterly, Vol. 4, No. 2, 1980, pp.
45-55. doi:10.2307/249336