See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220204290

Software Development Project Risk Management: A New Conceptual

Framework

Article  in  Journal of Software Engineering and Applications · January 2011

DOI: 10.4236/jsea.2011.45032 · Source: DBLP

CITATIONS READS

23 5,703

2 authors:

Lazaros Sarigiannidis Prodromos D Chatzoglou

International Hellenic University Democritus University of Thrace
48 PUBLICATIONS   670 CITATIONS    132 PUBLICATIONS   3,112 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

“Talent retention in the era of change and knowledge: enhancing employee engagement” under the call RESEARCH SUPPORT WITH EMPHASIS ON YOUNG
RESEARCHERS PHASE B View project

ED-BPR View project

All content following this page was uploaded by Lazaros Sarigiannidis on 28 May 2014.

The user has requested enhancement of the downloaded file.

Journal of Software Engineering and Applications, 2011, 4, 293-305 293
doi:10.4236/jsea.2011.45032 Published Online May 2011 (http://www.SciRP.org/journal/jsea)

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: [email protected]

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 line 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 does not appear to be widely accepted within the soft-

ware engineering community. Dedolph [14] implies
Risk management has been applied to various fields
that the reason for the software risk management ne-
like the national security, exploration of space, nuclear
reactors, security, construction industry and financial glection is primarily the organizational inertia and their
investments [1]. This research will focus on the study native resistance to change, due to the difficulty of risk
of various approaches of risk management applied to management value assessment, the lack of resources,
software development projects. Although they have the need for structural changes and other.
been applied with success in the last decades, dealing Given the complexity of most software projects and
with problems in the development of various systems, the several risk types emerged during the develop-
the fact that a large percentage of the systems is never ment/implementation stages, the abandonment of risk
completed, or fails to operate effectively and efficiently management to human intuition and initiative [15] can
[2-11], renders the study of these approaches even sometimes be proven effective, yet remains an insuffi-
more imperative. cient substitute of the constant professional and stable
The fact that the majority of the software develop- approach of risk management.
ment organisations perceive risk in a different and not Risk management of software development projects
systematic way contributes to the increase of project was recognised as an independent field of research in
development instability and ineffectiveness. Kwak and 1989, when Barry W. Boehm lead the way with his
Ibbs [12] identified risk management as the least ap- pioneering book “Software Risk Management”. Since
plied scientific field among the various knowledge ar- then, this particular issue has been discussed and stud-
eas of project management. In line with Kwak and Ibbs ied quite thoroughly, especially in the beginning of ’90s.
study, Adams and Pinto [13] research states that risk The work of Boehm [16,17] and Charette [18,19] laid the
management has not received sufficient attention and foundations for the extensive contribution of the Soft-

Copyright © 2011 SciRes. JSEA

294 Software Development Project Risk Management: A New Conceptual Framework

ware Engineering Institute (SEI) in the middle of ’90s project managers.

[20-25], that even today acts as an archetype in several
2.2. Project Characteristics
references in risk management literature.
The goal of the current study is the creation of a new The factors that characterize and, in many occasions,
research model, which emerged from a thorough ex- shape the development process of a project, affect to a
amination of the literature, and will be used to measure great extend the determination of its risk level. In the
various conceptual factors and their relationships in present research, five main characteristics of the software
order to achieve a better and more complete under- development projects will be studied.
standing of risk management as an organisational The first of these is Project Scope, which in this case is
process. In doing so, the effect of several organisa- going to be studied through an indicator, Project Dura-
tional strategies and characteristics on the determina- tion [31,32]. This indicator is selected as the measure for
tion of the risk level of software projects, as well as its project scope because, as Wallace et al. [32] propose, the
consequential influence on the total project perform- collection of duration information is easy for most pro-
ance, will be assessed. In Sections 2 and 3 the concep- jects and it is suitable to survey-based data collection
tual framework and the research questions are pre- procedures.
sented, respectively, while some concluding remarks The second characteristic has to do with whether a
are provided in Section 4. project is carried out totally In-house or in collaboration
with external providers (Outsourcing) [33]. It has been
2. Literature Review stressed that outsourcing, as a strategy of gaining com-
2.1. Risk Identification Approaches petitive advantage for a company, is particularly effec-
tive yet equally risky (due to the complexity and some-
As Schoenthaler [26] mentioned, based on his practical times the vagueness that characterize its procedures)
experience, it is undeniable that the systematic use of risk compared with the in-house method [32,34,35]. Still,
management into the project development process will despite the rapid increase of outsourcing in developing
have a considerable negative impact on project risks software projects in the past few years (in 2005, 75% of
level. In an attempt to promptly, effectively and easily the USA organizations outsource to some extent), its
identify risk, managers of software projects have been effect on the projects’ risk level, and especially on those
using various methods. Four of them are going to be dis- taking place in countries with less developed infrastruc-
cussed below, in a similar way as they were classified by tures, have been studied poorly by literature [36].
Kulik and Weber [27]. The third characteristic of a software project that will
The first one is the Ad-hoc Approach, which provides be examined by this study is its Strategic Orientation
an assessment of risks when the initial symptoms appear [32,37]. The strategic nature of a system can be measured
on the project, as well as their mitigation with unofficial by the classification of the projects as 1) strategic, 2)
way. The second approach is called Informal Approach organizational and 3) informational.
[28] and includes a discussion with people, who are di- Moreover, Project Diversity constitutes a structural
rectly or indirectly involved with the project, concerning form that is expressed in work specialization terms [38].
the several risk issues that appear (or will possibly appear) In this research, the project diversity will refer to the dif-
and the recording and documentation of the risks for fu- ferentiation level that appears in the knowledge back-
ture use. The third is named Periodic Approach and, as it ground, capabilities and experience among the project
can be understood from its title, involves the use of re- development participants [39].
petitive procedures for the identification and specifica- The fifth and final characteristic is the Type of System
tion (quantitatively and qualitatively) of the risks. Finally, being developed [5,40,41]. The failure to identify, under-
the fourth approach is the Formal Approach for the iden- stand and confront the risks that are connected to differ-
tification of the various risks [29]. According to this ap- ent project types is an important and defining factor for
proach, a thorough and in-depth assessment of each risk the problems during the realization of the project, con-
by independent individuals is performed. cealing the real project risks from their developers (that
An international research on software development is, by differentiating the perceptions that they have
risk management, carried out in 2001 by the Research formed for them) [42]. Six main types of software de-
Corporation KLCI, indicated that the most common risk velopment projects can be distinguished [5], in spite of
identification approach is the informal, used by 37% of Glass [3] statement for curious biases and omissions in
the respondents, while Ropponen’s [30] study enforces Jones’ list: 1) Management Information Systems, which
the impression of the absence of a framing thinking about are the most common software applications, 2) System
software risk concept and managerial implications by Software, like for example the operating systems involv-

Copyright © 2011 SciRes. JSEA

 Software Development Project Risk Management: A New Conceptual Framework 295

ing software that facilitates software applications (Ap- of systems integration. Houston [53] also proposed a list
plication Software), 3) Commercially-marketed Software, of 29 software development risk factors, considering
4) Military Systems, which are created for securing rules them as the most important and frequently cited in the
and models in military data, 5) Contract or Outsourced existent literature. Cule et al. [54] categorize risks into
Software projects in the civilian domain, and 6) End-user four dimensions according to their source (task, client,
Software projects (software developed by users, not pro- environment, self), which includes 55 software risks, and
grammers). they proposed a risk management strategy for each di-
mension. Sumner [55], through structured interviews,
2.3. Risk Dimensions
compared the differences of software risks between MIS
Barki et al. [43] suggest that the software project risks and ERP projects and proposed nine risks that are unique
consist of interrelated dimensions and their assessment in ERP projects. Kliem [56] developed a list of 38 risks
should not be made with the use of a one-dimension in BPR (Business Process Reengineering) projects,
scale, but, on the contrary, every dimension should be which were categorized in 4 main dimensions: people,
defined separately, theoretically as well as empirically. management, business and technique. Schmidt et al. [57]
The multidimensional assessment of risk can supply a identified 53 risk variables that were categorized in 14
clear specification for research and practical purposes factors and suggested that the difference in the culture of
[44]. the three countries (Finland, China and USA) where their
Despite the significance of studying risk through its research was carried out, could affect considerably the
dimensions, very few researches have been carried out on list of risks. They finally concluded that only 11 of them
this issue. McFarlan [45] found three major dimensions have cross-cultural application. Addison [58] has used
of risk in the software development process: project size, the Delphi technique to collect the opinions of 32 spe-
technology experience and project structure. He sug- cialists and then presented a list of 28 risks for e-commerce
gested, also, that project administrators should develop a projects.
complete and aggregated software risk profile for every This research will mainly be based on the dimensional
software project. Boehm [17] proposed a software risk distinction of a quite recent approach, the one proposed
management framework that included the evaluation and by Wallace et al. [48]. They proposed 27 software de-
control of risk and conducted a list with the top ten risks velopment risks that could be grouped into six dimen-
based on his personal professional experience. In spite of sions, those referring to: Users [57,59-61], System Re-
all these, Boehm’s list was lacking some theoretical sub- quirements [18,59,62,63], Project Complexity [43,64,65],
stantiation [46] and, moreover, due to its complexity and Planning and Control [57,59,66,], Team [63,67-69] and
other factors that characterize software projects (e.g. in- Organizational Environment [5,43,70].
visibility, flexibility and conformity) [47], it ceased hav- However, in contrast to the Wallace et al. [48] study,
ing any diachronic value. Barki et al. [43] conducted a that evaluates only the extent to which each risk state-
comprehensive review of studies related to software de- ment characterized the projects, and in line with Han and
velopment risk and then they proposed 35 measures for Huang [59] research, this study will attempt to assess
its estimation. These measures were categorized in five both the probability of occurrence and the impact for
dimensions: technological newness, application size, each risk by the respondents, determining the risk level
expertise, complexity of the application and organiza- of each dimension. In order to calculate the risk exposure
tional environment. Although this research delivered a (RE) for each risk item, the formula of Cooper et al. [71]
quite useful and understandable instrument for measuring will be adopted. They propose that the traditional meas-
risk, it was noticed that the risk evaluation scale was ex- urement of RE, as the product of possibility and conse-
tremely complicated [46,48]. Heemstra and Kusters [49], quence (RE = P*C) [17,28,49,59,72-74,] has significant
based on previous studies and their professional experi- disadvantages due to the fact that elements with high
ence, composed a list of 36 risk variables that were later consequence, yet low possibility, can return low risk ex-
grouped into 9 categories. Moynihan [50], in co-opera- posure factors and as so they can be falsely considered as
tion with 14 experienced Irish application developers, insignificant. More specifically, they measure the RE
evolved a total of 21 points that are risk related. Roppo- with the following formula: RE = P + C – (P*C) (the
nen and Lyytinen’s [51] questionnaire was relied on equation works only if the possibility of a risk to occur
Boehm’s [17] checklist, and distinguish 6 risk compo- and the severity of its impact are in a scale from 0 to 1)
nents based on a survey of project managers including [71]. The adoption of this formula in this study will
almost 1100 projects. Furthermore, the Hierarchically hopefully give more stabilized, objective and realistic
Holographic Modeling framework, introduced by Long- data about the significance, and hence the impact, of each
staff et al. [52], brings out 32 risks in seven dimensions risk dimension on the project.

Copyright © 2011 SciRes. JSEA

296 Software Development Project Risk Management: A New Conceptual Framework

2.4. Project Risk Management Team the project risk profile, the residual performance risk can
be decomposed in two parts, based on the following
Many critical decisions are made by teams rather than by
equation [36,83]:
individuals, because group decisions are more consistent
Residual Performance Risk = Residual Controllable
with rationality than individual ones [75]. In this study,
Risk + Unforeseeable Risk
the concept of the project risk management team will be
The Residual Controllable Risk is expressed by the
also examined. This concept incorporates many diverse
uncertainty that continues to exist during the final stages
roles, such as the compilation and evaluation of the re-
of the software development projects that can be con-
quired project risk information and its sharing with the
trolled, and even limited, with various ways. The Un-
project risk manager, and also requires a detailed under- foreseeable Risk is the uncertainty that cannot be identi-
standing of the current project risk management method- fied or controlled while planning the project. However,
ology being used [76]. However, nowadays, most risk despite the intention of previous studies [83] to examine
analysis projects are unsuccessful since the internal ex- these two dimensions of residual performance risk sepa-
perts and subject matter experts are excluded from the rately, no effort of this kind is recorded until today in the
process [77], or there is not sufficient information about international literature. In the present study, a first at-
their personal characteristics, abilities and attitude to- tempt of disintegrating the factor of residual performance
wards risk. Ward [78] underlined this insufficiency and risk will be made, on the basis of the variables defined by
attempted to trace and theoretically analyze the most Na et al. [83, 36] and their classification according to
significant characteristics of the project participants who their notional coherence to the theory.
have taken on the difficult task of risk management.
These characteristics include the Capability and Experi- 2.6. Project Performance
ence of the participants, their Motivation for accepting to The present research will concentrate on the project per-
undertake initiatives, which importance has been stressed formance related results since performance is the de-
by Boehm [79], and the Perceived Responsibilities in risk pendable variable of most vital importance [81].
management. Despite the thorough and analytical theo- The performance of a software development project
retic foundation of the project risk management team can be divided, for reasons of better, deeper and more
concept, Ward [78] did not provide a research instrument circumstantial studying, into two main categories: the
for the measurement of this construct. In order to opera- subjective and the objective performance [36]. These two
tionalize this construct, a deductive scale development categories used for measuring the performance are quite
approach will be utilized, while the development of the important for software developers, and users as well,
items will be based on the theoretical definition of the since both of them affect directly or indirectly the execu-
construct [80]. tion and implementation of every project [84].
2.5. Residual Performance Risk The factor of subjective project performance refers to
the efficiency and efficacy by which a software devel-
The primary performance influence mechanism of a opment project is completed (according to the people
software project is a risk called Performance Risk which involved in the project) [85] and bears in mind two basic
represents the difficulty in evaluating the final perform- dimensions [72,83,86]: the process performance and the
ance in terms of cost and schedule overruns [81]. Ac- product performance.
cording to Nidumolu [65,81], the estimated performance Process Performance is an efficiency measure for the
risk that is detected in the final development stages of a software development process and can be described by
project is called Residual Performance Risk. This defini- three dimensions [81]: 1) the increase in the gained
tion is used to clearly distinct it from the risk that is knowledge during the implementation of the project
found during other phases in the project’s development which is called Learning, 2) the management level in the
life cycle. Therefore, this risk refers to the difficulty in development process that is named Control and 3) the
assessing the consequences of executing the project, quality of the relationship among the various participants
during the final phase of its development. (managers, technicians, analysts, programmers, external
Meyer et al. [82] introduced a more “forward think- specialists, users etc.) through the duration of the soft-
ing” approach that emphasizes on the uncertainty frame ware development process, that is called Quality of In-
of a project. These researchers have agreed that, apart teractions [87].
from the predictable uncertainty that can be controlled by Product Performance is a measure for registering and
the traditional methods of risk management, an unex- illustrating the performance of the final product and is
pected uncertainty and a general chaos appears in many described by the following three dimensions [65,81]: 1)
innovative projects. As a consequence of this notion of the technical performance of the software, that is called

Copyright © 2011 SciRes. JSEA

 Software Development Project Risk Management: A New Conceptual Framework 297

Operational Efficiency, 2) the respond quality to the process quality and requirements difficulty. Development
needs of the software users, that is noted by the term Re- and testing process quality consists of variables measur-
sponsiveness and 3) the ability of the software to provide ing the regularity of reviews, the quality of documenta-
perceptible support to new products and functions and its tion and the level of independent testing. In the Age-
Flexibility to the interchangeable organizational needs. naRisk manual of software risk modelling [95] for meas-
These two dimensions of project performance need to uring the development and testing process quality, one
be estimated separately since there is not necessarily a more indicator is used—a model of the maturity of the
high relationship between them [72]. For example, it is capabilities that an organization has in executing specific
quite possible that a project with cost or schedule over- organizational procedures, the Capability Maturity Model
runs problems will deliver a high quality product and (CMM) [96]. In the present research CMM was omitted,
vice versa. mainly due to the non-categorisation of many companies
Although the measurement of subjective performance worldwide (especially in underdeveloped or developing
has the plain advantage of the easy collection of neces- countries) to its five levels [47,97].
sary data [36], it deals intensely with the problem of A summary of the research constructs that compose
standardization, since the evaluation of a project depend the general risk management model is presented in Table
on personal judgement or moreover the mood of a certain 1, along with the number of items that measure them.
manager [84]. What’s more, Figure 1 illustrates the relationships that
Contrary to the subjective performance of a project, exist between them, which will be examined thoroughly
the objective performance includes some more quantified in the following section.
metrics like, for example, excess in terms of cost, effort
and schedule. According to literature [36,88,89], it is Table 1. Summary of research constructs.
suggested to measure both subjective and objective pro- Factors Sub-factors Items References
ject performance, due to the special nature that charac- Strategic
3
terizes software development projects. Orientation
Project Scope 1
2.7. Project Quality Project
Outsourcing 1
[5,31-33,
Characteristics 37-39,98]
Another factor that can significantly define risks, as well Project Type 3
as the level of their presence during the process of a pro- Project
3
Diversity
ject’s software development, is project quality [90,91]. In
Risk Identifica-
the present study, the total quality of a project will be tion Ap- - 4 [27]
defined through the measurement of two main factors proaches
and the variables that define them according to literature User 5
[92,93]. These two fundamental factors are: process System
4
Requirements
quality [94] and people quality. To begin with, people Project [5,17,31,40,
4
quality is divided into two main sub-factors, so that it can Risk Dimen- Complexity 43,45,
be measured with the utmost detail. These two sions Planning and 48-50,52,
7
Control 54-68,70]
sub-factors that compose it are management quality and Team 3
staff quality. Organizational
4
Management quality includes variables like commu- Environment
nications management adequacy, subcontract manage- Project Risk
Management − 3 [62,78]
ment adequacy, interaction management adequacy and Team
internal management quality [95]. On the other hand, Residual
people quality involves the quality of non-administrative Residual Controllable 2
[36,45,65,
Performance Risk
staff that is occupied with a project. For its measurement, 81-83,99]
Risk Unforeseeable
4
variables like staff turnover, staff experience, staff moti- Risk
vation, staff training and programming language experi- People Quality 10
ence are used [92]. Project Quality Process [47,90-96]
6
Quality
Process quality is a complex factor for defining project
Subjective [36,48,59,
quality; it associates the project specification clarity with Project Performance
24
65,72,81,
the development and testing process quality. Specifica- Performance Objective 83,86,88,
3
tion clarity is defined by the variables of specification Performance 89,97,100]

Copyright © 2011 SciRes. JSEA

298 Software Development Project Risk Management: A New Conceptual Framework

Figure 1. Conceptual framework.

3. Conceptual Framework requirements as well. In total agreement with the survey

of Huang and Han [46], two earlier surveys, those of
3.1. The Relationship between Project
Wallace et al. [32] and Zmud [101], verified this parallel
Characteristics and Project Risk
relationship of project scope with risk. Wallace et al. [32]
In literature, there is a lack of studies that attempt to ex- detected a clear influence of project scope on all risk
amine the various characteristics of software projects and dimensions, while Zmud [101] suggested that the higher
the way different risk dimensions, especially, and the level of uncertainty that is observed on projects with long
total level of risk, in general, are affected by them. This duration is an outcome of the co-dependence between the
research will examine, five project characteristics, emerged various project procedures and the high level of
from the literature, which have been discussed above co-operation that should be accomplished for the har-
[5,32,38]. monic and effective management of people, of require-
First, the development of an application with strategic ments and complexity.
orientation has fundamental differences from the devel- Wallace et al. [32] revealed the insufficiency of sur-
opment of an application for automating various transac- veys about the relationship between the use of outsourc-
tions or decision-making. For example, the survey of ing and project risk, and they verified that the use of
Wallace et al. [32] showed that strategic applications outsourcing would bring a different risk profile compared
involve more complexity risk than information or trans- to the complete use of intra-organizational resources for
action oriented applications. Yet, though it seems quite the development of a project. The use of one indicator for
possible that projects of strategic nature differ from the two different strategies (in-house and outsourcing), in
non-strategic projects in terms of risk, far too few em- conjunction with the risk dimensions metrics, can lead to
pirical researches have been carried out examining the the exploration and projection of the main sections of a
role various project characteristics play in the appearance project that become more or less risky, according to the
and magnitude of these risks. selection or not of an outsourcing strategy for their de-
Moreover, although the relationship between project velopment. Through the empirical results of their survey,
scope and software project risk is known from unpub- Wallace et al. projected the highest levels of risk on the
lished experiences, it has not been empirically tested in dimensions of team and planning and control, in those
depth. However, a research by Huang and Han [46] ele- cases that an organization decides to make use of the
vated the fact that a parameter of the project scope, its outsourcing strategy. In order to explain this limited rela-
duration, affects to a great extent some of the dimensions tionship of outsourcing with the total level of risk (as it is
of risk, like those of planning and control, team, user and defined by its 6 aforementioned dimensions), they stated

Copyright © 2011 SciRes. JSEA

 Software Development Project Risk Management: A New Conceptual Framework 299

that projects that are liable to outsourcing practices, justi- 3.3. The Relationship between Project
fiably tend to encounter greater challenges and difficul- Characteristics, Project Risk Management
ties, in terms of team communication and co-operation, Team and Project Quality
provided that at least two organizations are engaged.
After the analysis of those variables that define some of
The issue of project diversity - although it has been a
the elements that characterize a software project as well
matter of examination in the field of software develop-
as its stakeholders, and their connection to the project
ment many times in the past [38,39,98], concerning its
risk, an attempt will be made to examine their interaction
relation and effect on the degree of success and per-
with project quality. The specific conceptual connection
formance of a project- is obviously absent from the in-
among these volatile factors, despite its obvious theo-
ternational literature, as regards the examination of its
retical and practical value, has not been studied in depth
relationship with the risk level of software projects. in the past, at least not in the restricted framework of
Last but not least, Jones [5] defined six basic catego- software development. For this reason, the examination
ries of software projects and correlated them with the and interpretation of these relationships were considered
most risky factors of the project, recognizing that differ- essential, despite their indirect reference to the main is-
ent risks affect different software systems with different sue of the emergence, impact, mitigation and overall
weight. Though, the Application Taxonomy catalogue management of project risks. No matter what results-con-
that Jones presented constitutes an interesting contribu- clusions will be derived, a wider research framework in the
tion in the field of risk management, his research suffers field of risk management in the international literature
many paradoxical tendencies and omissions that should will be hopefully triggered.
be improved through future research. The present study Research Question 3: How Project Characteristics
is going to proceed towards this direction. affect Project Quality?
The main research question that emerges from the Research Question 4: How Project Risk Management
above discussion, illustrated in Figure 1, is the follow- Team Characteristics affect Project Quality?
ing:
Research Question 1: How the characteristics of a 3.4. The Relationship of the Risk Identification
project affect the level of risk during the development Approaches with Project Risk and Project
process? Performance
3.2. The Project Risk Management Team Kulik and Weber [27] classified the risk identification
Relationship with Project Risk approaches for software projects in four main groups:
ad-hoc, formal, informal and periodic. In the present re-
The importance of selecting the appropriate team that search a step forward is going to be made, attempting to
will carry out the risk management process, so as to en- connect directly the risk identification approaches with
hance the effectiveness and performance of a project, the level of risk in the software development project and
was recognized by Ward [78]. Ward expressed the view with the project performance. These relations will be
that an effective risk management requires from project studied in order to estimate the importance, uniqueness
development team members to have the necessary moti- and effectiveness of every approach on the overall pro-
vation, capability and experience, as well as a deep un- ject risk assessment (as well as with each risk dimension)
derstanding of their responsibilities both for the process and on project performance, respectively.
and the outcome. He also stated that, if one of these re- Research Question 5: How does the use of different
quirements (motivation, capability and experience, per- risk identification approaches on software projects affect
ceived responsibilities) is missing, or cannot be elevated, the level of project risk involved?
then it will be desired to find a more adequate party for Research Question 6: How does the use of different
managing risk. Recognizing the importance of project risk identification approaches on software projects affect
participants’ characteristics for the risk management project performance?
process, as well as their effect on the total project per-
formance, an attempt will be made to connect these 3.5. The Relationship between Project Quality
characteristics with the software development risk. The and Project Risk
examination of this link is another goal of the present Despite the fact that the quality issue in software devel-
study. opment project has been taken into consideration in
Research Question 2: How the characteristics of the many research papers in the past (see Section 2.7), none
risk management team affect the level of project devel- of these studies investigated its importance and relation-
opment risk? ship with the conceptual factor of software development

Copyright © 2011 SciRes. JSEA

300 Software Development Project Risk Management: A New Conceptual Framework

risk. In this study, a first attempt will be made to con- Furthermore, since the Korean research [83] was de-
ceptualize this framework using the items suggested by signed to copy the previous American research [81], Na
Fenton’s et al. [92] research for measuring project qual- et al. did not try to collect data that would allow them to
ity. analyse the two elements of residual performance risk.
Research Question 7: How does the level of project As a result, they could not define the proportion of the
quality affect its risk? unforeseeable risk and the residual controllable risk
(through the aforementioned control techniques, at the
3.6. The Relationship of Residual Performance
final stage, though, of the development of a project), in
Risk with Project Performance
the total residual performance risk. For this reason, an-
Nidumolu [81] was the first to examine the relationship other contribution of the present study would be the se-
between project’s residual performance risk and its actual lection of appropriate data that will allow us to study and
performance. Data from 64 software development pro- analyse thoroughly these two elements of a project’s re-
jects in the USA provided substantial foundation for his sidual performance risk. Na et al. [83] stated that since
model. Nidumolu used residual performance risk as an managers of software projects continue to improve risk
intermediate factor among those of standardization, un- management practices, the mean residual controllable
certainty of requirements and project performance. After risk would gradually decrease. However, as the software
the statistic analysis and the examination of the hypothe- development becomes more and more innovative and the
ses, Nidumolu enunciated the existence of a negative development technology continues to improve rapidly,
consequence of residual performance risk on the process the risk of unexpected uncertainty and chaotic situations
and product performance of the project. could emerge and quickly take gigantic dimensions.
Na et al. [83] attempted to examine the original model Research Question 8: How does residual performance
of Nidumolu’s survey in the software development in- risk affect the performance (subjective and objective) of
dustry of Korea. By using identical structural models and a project?
by gathering data from Korean software projects that Research Question 9: How does unforeseeable risk
were developed from 1999 to 2000, they compared the and residual controllable risk affect the residual per-
findings of Nidumolu from the USA with those of their formance risk of a project?
research. The analysis indicated that the mean of residual
3.7. The Relationship of the Project Risk with
performance risk and its effect on the subjective per-
the Project Performance
formance of a project differs significantly between the
two studies and the two countries, since the correlation The relationship between the risk level of a project and
coefficients between both residual performance risk and its performance has been examined by several researches
the two aspects of project performance are not statisti- in the past [32,48,59,100]. In particular, Jiang and Klein
cally important for the data of the Korean research. Ac- [100] agreed that the various risks in software develop-
cording to Na et al. [83], a possible explanation for this ment consist a great problem that affects project per-
observed difference is that in technologically developing formance. Wallace et al. [32] composed a model – that
countries like Korea, where the systematic use of risk was established in the literature of project management
management is still in early stages, the residual perform- and the sociotechnical theory, along with the special risk
ance risk is less important and substantial for software metrics – that is based on six risk dimensions and ex-
development companies. plains to a great extent the variability that occurs on the
Extending the previous research, Na et al. [36] carried project performance. Wallace et al. [48] designed a
out a survey in three of the largest software development model measuring project’s performance and risk level,
companies in Korea (companies that occupied at least and they underlined the reverse relationship between the
25.000 employees). In this survey, Na and his colleagues two concepts (especially the process instead of the prod-
attempted to measure (in 123 software development pro- uct). Recently, Han and Huang [59] examined the rela-
jects), among others and the relationship between the tionship of software risks and their effect on project per-
residual performance risk and the objective performance formance. In their article, they displayed the findings of
of projects. They reported the existence of a positive and an empirical research that was based on 115 software
statistically important relationship between these factors. projects, about the possibility of appearance and the
A recent study by Jiang et al. [99] measured and consequence of the six different dimensions of risks on
evaluated the effect of the residual performance risk on project performance.
the subjective performance of 151 organizations in the Considering the above surveys, and since the empirical
USA This research verified the negative relationship data that describe the relationship between risk and pro-
between these two factors. ject performance are rare and often fail to take into con-

Copyright © 2011 SciRes. JSEA

 Software Development Project Risk Management: A New Conceptual Framework 301

sideration the several risk factors that prevent their suc- ages among software project risk, risk identification ap-
cessful outcome, this study may emerge as a general proaches, project characteristics, project risk manage-
framework for future research, so as to investigate the ment team, residual performance risk, project quality and
impact of project risk on both dimensions (subjective and project performance.
objective) of performance, and to further examine those In addition, it must be stressed that another significant
risk factors that are less projected in literature and have goal of this paper is the recording and examination of
an important effect on project performance. these parameters of risk management in software devel-
Research Question 10: How does the level of project opment projects that can induce and motivate managers
risk affect the performance (subjective and objective) of or project team members, to a more energetic role in the
a project? risk management practices. This study has provided
many visions of software project risk that project man-
4. Concluding Remarks
agers should utilize in order to manage the potential risks
In spite of the indisputable fact that in the past 20 years related with a particular project and to evaluate effec-
there have been noticed remarkable efforts internation- tively the possible alternatives. The multi-dimensional
ally (found in literature), it is true that quite enough is- theoretical background of these practitioners is almost
sues concerning risk management in software develop- certain that will provide the necessary spark for the use
ment projects remain unexamined and lack theoretical of a thorough and systematic approach of risk manage-
and practical support. The expected goal of this research ment in the whole project lifecycle (in which risk is as-
is to bridge the gap between the existing literature and sessed in each phase of the project), and to develop the
the appropriate practices in the management of software appropriate risk mitigation strategy in more timely and
development projects by evaluating practitioners’ needs scientific way.
for the successful management of software risks. Finally, the project risk management issues are not
Through a brief literature review and the construction usually in the agenda of the software development or-
of a new research framework, an explicit conceptual ganizations (and especially at the small ones), because of
framework has been formed. In this framework, a group the sensitive information that includes and the adherence
of factors has been added for the determination of the to the “shoot the messenger” syndrome, which frequently
total risk level and, moreover, its effect (and all of the discourages the members of the development team from
dimensions that compose it) on the final subjective and bringing forthcoming or pending problems to the atten-
objective project performance. The ineffective perform- tion of management. So, this study may help to get over
ance of many software projects and the consequential this lack of communication between project team mem-
costs and time overruns, missed business prospects, and bers (who will find some helpful and practical insights in
the rise of social distrust in the information technologies, the theoretical framework of this research) and, mainly,
give cause for reflection in the software project man- by changing and integrating a new effectual culture con-
agement field; this study will hopefully help in the sidering the risks that their projects face.
evaluation and estimation of several project performance The research model suggested here has to be validated
related aspects. using real life data. Authors have already constructed a
Part of the value of this framework lies in the concep- structured questionnaire which has been refined in sev-
tual representation of factors and the examination of the eral pre-test stages and interviews with academics and
possible relationships between them, which have not practitioners (project managers and programmers) ex-
received the appropriate attention when thinking about perts in software project development. The data collec-
managing software development projects. While the tion process will commence by the end of January, 2011,
value of the risk management has already been under- while the first results are expected by the end of March,
lined in the past, and the fact that its theory has made a 2011.
lot of advancements, there is no complete model yet de-
scribing and analyzing the relationships between all these REFERENCES
organizational concepts in detail. More specifically, [1] J. H. Iversen, L. Mathiassen and P. A. Nielsen, “Manag-
within the field of software development project risk ing Risk in Software Process Improvement: An Action
management, there is not an extensive, well-grounded, Research Approach,” MIS Quarterly, Vol. 28, No. 3,
distinct and applicable system, which will be able to 2004, pp. 395-433.
guide project managers to follow reliable and successful [2] W. W. Gibbs, “Softwares Chronic Crisis,” Scientific Ameri-
management mechanisms. The proposed framework is can, Vol. 271, No. 3, 1994, pp. 86-95.
considered to be an original and complete model that doi:10.1038/scientificamerican0994-86
intends to contribute to literature by exploring the link- [3] R. Glass, “Software Runaways—Some Surprising Find-

Copyright © 2011 SciRes. JSEA

302 Software Development Project Risk Management: A New Conceptual Framework

ings,” The DATABASE for Advances in Information Sys- [20] M. J. Carr, S. L. Konda, I. Monarch, F. C. Ulrich and C. F.
tems, Vol. 28, No. 3, 1997, pp. 16-19. Walker, “Taxonomy-Based Risk Identification,” SEI Re-
[4] J. Johnson, “My Life is Failure: 100 Things You Should port CMU/SEI-93-TR-6, Carnegie Mellon University,
Know to Be a Successful Project Leader,” Standish Pittsburgh PA, 1993.
Group International, West Yarmouth, 2006. [21] A. J. Dorofee, J. A. Walker, C. J. Alberts, R. P. Higuera,
[5] C. Jones, “Assessment and Control of Software Risks,” R. L. Murphy and R. C. Williams, “Continuous Risk
Yourdon Press, Englewood Cliffs, 1994. Management Guidebook,” Carnegie Mellon University,
Pittsburgh, 1996.
[6] C. Jones, “Risks of Software System Failure or Disaster,”
American Programmer, Vol. 8, No. 3, 1995, pp. 2-9. [22] R. P. Higuera, D. P. Gluch, A. J. Dorofee, R. L. Murphy,
J. A. Walker and R. C. Williams, “An Introduction to
[7] G. Klein and J. J. Jiang, “Seeking Consonance in Infor- Team Risk Management,” SEI Report CMU/SEI-94-SR-01,
mation Systems,” Journal of Systems and Software, Vol. Carnegie Mellon University, Pittsburgh, 1994.
56, No. 2, 2001, pp. 195-202.
doi:10.1016/S0164-1212(00)00097-2 [23] R. P. Higuera and Y. Y. Haimes, “Software Risk Mana-
gement,” SEI Report CMU/SEI-96-TR-012, Carnegie
[8] K. Lyytinen and R. Hirschheim, “Information Systems Mellon University, Pittsburgh PA, 1996.
Failures—A Survey and Classification of the Empirical
Literature,” Oxford Surveys in Information Technology, [24] F. J. Sisti and S. Joseph, “Software Risk Evaluation
Vol. 4, No. 1, 1987, pp. 257-309. Method,” SEI Report CMU/SEI-94-TR-19, Carnegie
Mellon University, Pittsburgh PA, 1994.
[9] J. McManus, “Risk Management in Software Develop-
ment Projects,” Elsevier Butterworth-Heinemann, Am- [25] R. L. van Scoy, “Software Development Risk: Opportunity,
sterdam, 2004. Not Problem,” SEI Report CMU/SEI-92-TR-30, Carnegie
Mellon University, Pittsburgh PA, 1992.
[10] J. Ropponen and K. Lyytinen, “Can Software Risk Man-
agement Improve System Development: An Exploratory [26] F. Schoenthaler, “Risk Management in Challenging Busi-
Study,” European Journal of Information Systems, Vol. 6, ness Software Projects,” Proceedings of the 10th Anniver-
No. 1, 1997, pp. 41-50. sary IEEE Joint International Conference on Requirements
doi:10.1057/palgrave.ejis.3000253 Engineering, Essen, Germany, 9-13 September 2002, pp.
[11] D. Shafer, “Software Risk: Why Must We Keep Learning 1-3.
from Experience?” Dynamic Positioning Conference, [27] P. Kulik and K. Weber, “Software Risk Management
Houston, 28- 30 September 2004, pp. 1-19. Practices—2001,” KLCI Research Group, Dayton, 2001.
[12] Y. H. Kwak and C. W. Ibbs, “Calculating Project Man- [28] S. Ward, “Assessing and Managing Important Risks,”
agements Return on Investment,” Project Management International Journal of Project Management, Vol. 17,
Journal, Vol. 31, No. 2, 2000, pp. 38-47. No. 6, 1999, pp. 331-336.
[13] K. M. Adams and C. A. Pinto, “Software Development doi:10.1016/S0263-7863(98)00051-9
Project Risk Management: A Literature Review,” Pro- [29] K. Wiegers, “Know Your Enemy: Software Risk Man-
ceedings of the 26th National Conference, Organizational agement,” Software Development, Vol. 6, No. 10, 1998,
Transformation: Opportunities and Challenges, American pp. 38-42.
Society for Engineering Management, Rolla, October [30] J. Ropponen, “Software Risk Management—Foundations,
2005, pp. 635-641. Principles and Empirical Findings,” Jyvaskyla University
[14] F. M. Dedolph, “The Neglected Management Activity: Printing House, Jyvaskyla, 1999.
Software Risk Management,” Bell Labs Technical Jour- [31] S. Murthi, “Preventive Risk Management for Software
nal, Vol. 8, No. 3, 2003, pp. 91-95. Projects,” IT Professional, Vol. 4, No. 5, 2002, pp. 9-15.
doi:10.1002/bltj.10077 doi:10.1109/MITP.2002.1041172
[15] J. Kontio, G. Getto and D. Landes, “Experiences in Im- [32] L. Wallace, M. Keil and A. Rai, “Understanding Software
proving Risk Management Processes Using the Concepts Project Risk: A Cluster Analysis,” Journal of Information
of the Riskit Method,” Proceedings of the ACM SIGSOFT and Management, Vol. 42, No. 1, 2004, pp. 115-125.
6th International Symposium on Foundations of Software
Engineering, ACM Press, New York, November 1998, pp. [33] R. Hirschheim and M. Lacity, “The Myths and Realities
163-174. of Information Technology Insourcing,” Communications
of the ACM, Vol. 43, No. 2, 2000, pp. 99-107.
[16] B. W. Boehm, “Software Risk Management,” IEEE Press, doi:10.1145/328236.328112
Piscataway, 1989.
[34] P. D. Chatzoglou and L. Sarigiannidis, “Business Out-
[17] B. W. Boehm, “Software Risk Management: Principles sourcing and Organisational Performance: The Case of
and Practices,” IEEE Software, Vol. 8, No. 1, 1991, pp. the Greek Hotel Industry,” International Journal of Ser-
32-41. doi:10.1109/52.62930 vices Technology and Management, Vol. 11, No. 2, 2009,
[18] R. N. Charette, “Software Engineering Risk Analysis and pp. 105-127. doi:10.1504/IJSTM.2009.022520
Management,” Intertext Publications, New York, 1989. [35] R. T. Nakatsu and C. L. Iacovou, “A Comparative Study
[19] R. N. Charette, “Applications Strategies for Risk Analy- of Important Risk Factors Involved in Offshore and Do-
sis,” McGraw-Hill, New York, 1990. mestic Outsourcing of Software Development Projects: A

Copyright © 2011 SciRes. JSEA

 Software Development Project Risk Management: A New Conceptual Framework 303

Two-Panel Delphi Study,” Information and Management, Vol. 11, No. 4, 1996, pp. 333-346. doi:10.1057/jit.1996.7
Vol. 46, No. 12, 2009, pp. 57-68. [50] T. Moynihan, “How Experienced Project Managers As-
doi:10.1016/j.im.2008.11.005 sess Risk,” IEEE Software, Vol. 14, No. 3, 1997, pp.
[36] K. S. Na, J. T. Simpson, X. Li, T. Singh and K. Y. Kim, 35-41. doi:10.1109/52.589229
“Software Development Risk and Project Performance [51] J. Ropponen and K. Lyytinen, “Components of Software
Measurement: Evidence in Korea,” The Journal of Sys- Development Risk: How to Address Them? A Project
tems and Software, Vol. 80, No. 1, 2007, pp. 596-605. Manager Survey,” IEEE Transactions on Software Engi-
doi:10.1016/j.jss.2006.06.018 neering, Vol. 26, No. 2, 2000, pp. 98-112.
[37] E. Clemons, “Evaluation of Strategic Investments in In- doi:10.1109/32.841112
formation Technology,” Communications of the ACM, [52] T. A. Longstaff, C. Chittister, R. Pethia and Y. Y. Haimes,
Vol. 34, No. 1, 1991, pp. 22-36. “Are We Forgetting the Risks of Information Technol-
doi:10.1145/99977.99985 ogy?” IEEE Computer, Vol. 33, No. 12, 2000, pp. 43-51.
[38] A. M. Aladwani, “IT Project Uncertainty, Planning and [53] D. Houston, “A Software Project Simulation Model for
Success: An Empirical Investigation from Kuwait,” In- Risk Management,” Ph.D. Thesis, Arizona State Uni-
formation Technology and People, Vol. 15, No. 3, 2002, versity, Tempe AZ, 2000.
pp. 210-226.
[54] P. Cule, R. Schmidt, K. Lyytinen and M. Keil, “Strategies
[39] M. A. Campion, G. J. Medsker and A. C. Higgs, “Rela- for Heading off Project Failure,” Information Systems
tions between Work Group Characteristics and Effec- Management, Vol. 17, No. 2, 2000, pp. 65-73.
tiveness: Implications for Designing Effective Work doi:10.1201/1078/43191.17.2.20000301/31229.8
Groups,” Personnel Psychology, Vol. 46, No. 4, 1993, pp.
[55] M. Sumner, “Risk Factors in Enterprise Wide/ERP Pro-
823-850. doi:10.1111/j.1744-6570.1993.tb01571.x
jects,” Journal of Information Technology, Vol. 15, No. 4,
[40] D. Houston, G. Mackulak and J. Collofello, “Stochastic 2000, pp. 317-327.
Simulation of Risk Factor Potential Effects for Software doi:10.1080/02683960010009079
Development Risk Management,” Journal of Systems and
[56] R. Kliem, “Risk Management for Business Process Reen-
Software, Vol. 59, No. 3, 2001, pp. 247-257.
Gineering Projects,” Information Systems Management,
doi:10.1016/S0164-1212(01)00066-8
Vol. 17, No. 4, 2001, pp. 71-73.
[41] C. Jones, “Software Assessments, Benchmarks, and Best
[57] R. Schmidt, K. Lyytinen, M. Keil and P. Cule, “Identify-
Practices,” Addison-Wesley, Boston MA, 2000.
ing Software Project Risks: An International Delphi
[42] D. Gotterbarn and S. Rogerson, “Responsible Risk Study,” Journal of Management Information Systems,
Analysis for Software Development: Creating the Soft- Vol. 17, No. 4, 2001, pp. 5-36.
ware Development Impact Statement,” Communications of
[58] T. Addison, “E-Commerce Project Development Risks:
the Association for Information Systems, Vol. 15, 2005,
Evidence from a Delphi Survey,” International Journal of
pp. 730-750.
Information Management, Vol. 23, No. 1, 2003, pp. 25-40.
[43] H. Barki, S. Rivard and J. Talbot, “Toward an Assess- doi:10.1016/S0268-4012(02)00066-X
ment of Software Development Risk,” Journal of Man-
[59] W. M. Han and S. J. Huang, “An Empirical Analysis of
agement Information Systems, Vol. 10, No. 2, 1993, pp. Risk Components and Performance on Software Pro-
203-225. jects,” The Journal of Systems and Software, Vol. 80, No.
[44] M. Boban, Z. Pozgaj and H. Seric, “Strategies for Suc- 1, 2007, pp. 42-50. doi:10.1016/j.jss.2006.04.030
cessful Software Development Risk Management,” Man- [60] J. Jiang and G. Klein, “Risks to Different Aspects of Sys-
agement, Vol. 8, 2003, pp. 77-91. Tem Success,” Information and Management, Vol. 36,
[45] F. W. McFarlan, “Portfolio Approach to Information No. 5, 1999, pp. 264-272.
Systems,” Harvard Business Review, Vol. 59, No. 5, doi:10.1016/S0378-7206(99)00024-5
1981, pp. 142-150. [61] S. Sakhtevil, “Managing Risks in Offshore Systems De-
[46] S. J. Huang and W. M. Han, “Exploring the Relationship velopment,” Communications, Vol. 50, No. 4, 2007, pp.
between Software Project Duration and Risk Exposure: A 69-75.
Cluster Analysis,” Journal of Information and Manage- [62] B. Curtis, S. Ward and C. Chapman, “Roles, Responsibili-
ment, Vol. 45, No. 3, 2008, pp. 175-182. ties and Risks in Management Contracting,” Construction
[47] B. Hughes and M. Cotterell, “Software Project Mana- Industry Research and Information Association (CIRIA)
gement,” 4th Edition, McGraw-Hill, New York, 2006. Special Publication 81, 1991.
[48] L. Wallace, M. Keil and A. Rai, “How Software Project [63] O. Mizuno, T. Kikuno, Y. Takagi and K. Sakamoto,
Risk Affects Project Performance: An Investigation of the “Characterization of Risky Projects Based on Project
Dimensions of Risk and an Exploratory Model,” Decision Managers Evaluation,” Proceedings of the 22nd Inter-
Sciences, Vol. 35, No. 2, 2004, pp. 289-321. National Conference on Software Engineering, Limerick,
doi:10.1111/j.00117315.2004.02059.x 4-11 June 2000, pp. 387-395.
[49] F. J. Heemstra and R. J. Kusters, “Dealing with Risk: A [64] C. F. Kemerer and G. L. Sosa, “Systems Development
Practical Approach,” Journal of Information Technology, Risks in Strategic Information Systems,” Information and

Copyright © 2011 SciRes. JSEA

304 Software Development Project Risk Management: A New Conceptual Framework

Software Technology, Vol. 33, No. 3, 1991, pp. 212-223. [79] B. W. Boehm and R. Ross, “Theory-W Software Project
doi:10.1016/0950-5849(91)90136-Y Management: Principles and Examples,” IEEE Transac-
[65] S. R. Nidumolu, “The Effect of Coordination and Uncer- tions on Software Engineering, Vol. 15, No. 7, 1989, pp.
tainty on Software Project Performance: Residual Per- 902-916. doi:10.1109/32.29489
formance Risk as an Intervening Variable,” Information [80] T. R. Hinkin, “A Review of Scale Development Practices
Systems Research, Vol. 6, No. 3, 1995, pp. 191-219. in the Study of Organization”, Journal of Management,
doi:10.1287/isre.6.3.191 Vol. 21, No. 5, 1995, pp. 967-988.
[66] S. P. Keider, “Why Systems Development Projects Fail,” doi:10.1177/014920639502100509
Journal of Information Systems Management, Vol. 1, No. [81] S. R. Nidumolu, “Standardization, Requirements Uncer-
3, 1984, pp. 33-38. doi:10.1080/07399019408963043 tainty and Software Project Performance,” Information
[67] T. K. Abdel-Hamid, “A Study of Staff Turnover, Acqui- and Management, Vol. 31, No. 3, 1996, pp. 135-150.
sition, and Assimilation and Their Impact on Software doi:10.1016/S0378-7206(96)01073-7
Development Cost and Schedule,” Journal of Manage- [82] A. Meyer, C. Loch and M. Pich, “Managing Project Un-
ment Information Systems, Vol. 6, No. 1, 1989, pp. 21-39. certainty: From Variation to Chaos,” Sloan Management
[68] F. P. Brooks, “No Silver Bullet: Essence and Accidents of Review, Vol. 43, No. 2, 2002, pp. 60-67.
Software Engineering,” Computer, Vol. 22, No. 4, 1987, [83] K. S. Na, X. Li, J. T. Simpson and K. Y. Kim, “Uncer-
pp. 10-19. doi:10.1109/MC.1987.1663532 tainty Profile and Software Project Performance: A
[69] J. J. Jiang, G. Klein and T. Means, “Project Risk Impact Cross-National Comparison,” The Journal of Systems and
on Software Development Team Performance,” Project Software, Vol. 70, No. 1-2, 2004, pp. 155-163.
Management Journal, Vol. 31, No. 4, 2000, pp. 19-26. doi:10.1016/S0164-1212(03)00014-1
[70] S. L. Jarvenpaa and B. Ives, “Executive Involvement and [84] T. Singh, “Software Development Risk Management in
Participation in the Management of Information Tech- Information Technology Developing Countries: An As-
nology,” MIS Quarterly, Vol. 15, No. 2, 1991, pp. sessment on Subjective and Objective Performance,”
205-277. doi:10.2307/249382 Thesis, University of Alabama in Huntsville, Huntsville,
2005.
[71] D. F. Cooper, S. Grey, G. Raymond and P. Walker, “Pro-
ject Risk Management Guidelines: Managing Risk in [85] C. Wohlin, A. V. Mayrhauser, M. Host and B. Regnell,
Large Projects and Complex Procurements,” John Wiley “Subjective Evaluation as a Tool for Learning from
and Sons Ltd., Chichester, 2005. Software Project Success,” Information and Software
Technology, Vol. 42, No. 1, 2000, pp. 983-992.
[72] H. Barki, S. Rivard and J. Talbot, “An Integrative Con-
doi:10.1016/S0950-5849(00)00150-6
tingency Model of Software Project Risk Management,”
Journal of Management Information Systems, Vol. 17, No. [86] A. Rai and H. Al-Hindi, “The Effects of Development
4, 2001, pp. 37-69. Process Modelling and Task Uncertainty on Development
Quality Performance,” Information and Management, Vol.
[73] K. Padayachee, “An Interpretive Study of Software Risk
37, No. 6, 2000, pp. 335-346.
Management Perspectives,” Proceedings of the 2002 An-
doi:10.1016/S0378-7206(00)00047-1
nual Research Conference of the South African Institute of
Computer Scientists and Information Technologists on [87] J. Miller and B. A. Doyle, “Measuring the Effectiveness
Enablement Through Technology, Bela Bela, 2002, pp. of Computer-Based Information Systems in the Financial
118-127. Services Sector,” MIS Quarterly, Vol. 11, No. 1, 1987, pp.
107-124. doi:10.2307/248832
[74] S. L. Pfleeger, “Risky Business: What We Have Yet to
Learn about Software Risk Management,” Journal of [88] L. C. Briand, K. E. Emam and F. Bomarius, “COBRA: A
Systems and Software, Vol. 53, No. 3, 2000, pp. 265-273. Hybrid Method for Software Cost Estimation, Bench-
doi:10.1016/S0164-1212(00)00017-0 Marking, and Risk Assessment,” Proceedings IEEE In-
ternational Conference on Software Engineering, Kyoto,
[75] B. Rockenbach, A. Sadrieh and B. Mathauschek, “Teams
19-25 April, 1998, pp. 390-399.
Take the Better Risks,” Journal of Economic Behavior
and Organization, Vol. 63, No. 3, 2007, pp. 412-422. [89] A. R. Gray, S. G. MacDonell and M. J. Shepperd, “Fac-
doi:10.1016/j.jebo.2005.04.023 tors Systematically Associated with Errors in Subjective
Estimates of Software Development Effort: The Stability
[76] L. Labuschagne, “Project Risk Management Roles and
of Expert Judgement,” 6th IEEE International Symposium
Responsibilities,” 2010.
on Software Metrics, Boca Raton, 4-6 November, 1999,
http://www.zulanas.lt/images/adm_source/docs/2_full%20
pp. 216-227.
paperENG.pdf
[90] J. Herbsleb, D. Zubrow, D. Goldenson, W. Hayes and M.
[77] T. R. Peltier, “Risk Analysis and Risk Management,”
Paulk, “Software Quality and the Capability Maturity
Information Systems Security, Vol. 13, No. 4, 2004, pp.
Model,” Communications of the ACM, Vol. 40, No. 6,
44-56. doi:10.1201/1086/44640.13.4.20040901/83732.7
1997, pp. 30-40. doi:10.1145/255656.255692
[78] S. Ward, “Requirements for an Effective Project Risk
[91] M. Ould, “Managing Software Quality and Business
Management Process,” Project Management Journal, Vol.
Risk,” Wiley, Chichester, 1999.
30, No. 3, 1999, pp. 37-43.

Copyright © 2011 SciRes. JSEA

 Software Development Project Risk Management: A New Conceptual Framework 305

[92] N. Fenton, W. Marsh, M. Neil, P. Cates, S. Forey and M. [97] M. Keil, L. Wallace, D. Turk, G. Dixon-Randall and U.
Tailor, “Making Resource Decisions for Software Pro- Nulden, “An Investigation of Risk Perception and Risk
jects,” Proceedings of the 26th International Conference Propensity on the Decision to Continue a Software De-
on Software Engineering, Edinburgh, 23-28 May 2004, velopment Project,” The Journal of Systems and Software,
pp. 397-406. doi:10.1109/ICSE.2004.1317462 Vol. 53, No. 2, 2000, pp. 145-157.
[93] N. Fenton, M. Neil, W. Marsh, P. Hearty, L. Radliński doi:10.1016/S0164-1212(00)00010-8
and P. Krause, “On the Effectiveness of Early Life Cycle [98] P. J. Guinan, J. G. Cooprider and S. Faraj, “Enabling
Defect Prediction with Bayesian Nets,” Empirical Soft- Software Development Team Performance during Re-
ware Engineering, Vol. 13, No. 5, 2008, pp. 499-537. quirements Definition: A Behavioral Versus Technical
doi:10.1007/s10664-008-9072-x Approach,” Information Systems Research, Vol. 9, No. 2,
[94] G. Hoffman, “Integrating PSP and CMMI Level 5,” STC 1998, pp. 101-125. doi:10.1287/isre.9.2.101
Proceedings, 2003. [99] J. J. Jiang, G. Klein, S. P. J. Wu and T. P. Liang, “The
http://www.stc-online.org/stc2003proceedings/PDFFiles/ Relation of Requirements Uncertainty and Stakeholder
pres1001.pdf Perception Gaps to Project Management Performance,”
[95] AgenaRisk, “Software Project Risk Model Manual. The Journal of Systems and Software, Vol. 82, No. 5,
Bayesian Network and Simulation Software for Risk 2009, pp. 801-808. doi:10.1016/j.jss.2008.11.833
Analysis and Decision Support-AgenaRisk (Version 2.00),” [100] J. J. Jiang and G. Klein, “Software Development Risks to
2005. http://www.agenarisk.com/ Project Effectiveness,” The Journal of Systems and Soft-
[96] G. H. Subramanian, J. J. Jiang and G. Klein, “Software ware, Vol. 52, No. 1, 2000, pp. 3-10.
Quality and IS Project Performance Improvements from doi:10.1016/S0164-1212(99)00128-4
Software Development Process Maturity and IS Imple- [101] R. W. Zmud, “Management of Large Software Develop-
mentation Strategies,” Journal of Systems and Software, ment Efforts,” MIS Quarterly, Vol. 4, No. 2, 1980, pp.
Vol. 80, No. 4, 2007, pp. 616-627. 45-55. doi:10.2307/249336
doi:10.1016/j.jss.2006.06.014

Copyright © 2011 SciRes. JSEA

View publication stats