Department of Informatics

The Influence of Software Risk

Management on Software Project
Success
Master thesis 15 HEC, course INFM10 in Information Systems
Presented in [May, 2017]

Authors: Hiba Arafeh

Adham El-Ahmad

Supervisor: Azadeh Sarkheyli

Examiners: Bo Andersson
Paul Pierce
The Influence of Software Risk Management on
Software Project Success

Authors: Hiba Arafeh and Adham El-Ahmad

Publisher: Dept. of Informatics, Lund University School of Economics and Management.

Document: Master Thesis

Number of pages: [81]

Keywords: [Software Development, Software Project Management, Software Risks, Risk

Management, Software Risk Management, Software Project Success]

Abstract:

Software development project still of high failure rates. A diversity of risk management
approaches are suggested by researchers and followed by organizations in order to minimize the
failure rate and ensure project success. However, does risk management do always what it is
supposed to do? In this research, we survey field workers and interview project managers, to
investigate the influence of risk management on project success in practice, and to explore and
reveal situations where risk management could lead to failure. We also try to find if there is a
relation between risk management and different software project success criteria, as well as
customer satisfaction. We also give some recommendations to help field workers performing a
better risk management process.

I
 Acknowledgements
We would like to express our sincere gratitude to those who participated in our survey as well as
the interviewees who agreed to collaborate in the interviews. We would like to thank our supervisor
Azadeh Sarkheyli for her continuous guidance and positive attitude throughout our thesis research
process.

Special Thanks
I would like to express my gratitude I would like to thank my teachers,
to “Swedish Institute” for awarding my friends, and my beloved family
me the “Swedish Institute study for their support during my studies.
scholarship” to accomplish my Special thanks goes to Dr. Paul
Master studies at Lund University. Pierce from Lund University, as
I would also like to thank my family well as to Dr. Rüdiger Lincke from
and my beloved husband for their Linnaeus University in Växjö, for
encouragements, and support. their support and encouragement
during my studies.

Hiba Arafeh
Adham El-Ahmad

II
Contents
1. Introduction ............................................................................................................................. 1
1.1 Background ...................................................................................................................... 1
1.2 Related work .................................................................................................................... 1
1.3 Problem formulation ........................................................................................................ 2
1.4 Research questions ........................................................................................................... 2
1.5 Purpose ............................................................................................................................. 3
1.6 Delimitation...................................................................................................................... 3
1.7 Target group ..................................................................................................................... 3
1.8 Outline .............................................................................................................................. 3
2. Literature Review .................................................................................................................... 4
2.1 Software development life cycle ...................................................................................... 4
2.2 Software development risks ............................................................................................. 5
2.3 Software risk management ............................................................................................... 7
2.4 Software projects between success and failure ................................................................ 9
2.5 Software risk management and software project success .............................................. 10
2.6 Summary of literature review ......................................................................................... 11
3. Methodology.......................................................................................................................... 12
3.1 Method description ......................................................................................................... 12
3.2 Research approach.......................................................................................................... 12
3.3 Literature review ............................................................................................................ 13
3.3.1 Description of the literature review..................................................................................... 13
3.3.2 Validity of the literature review .......................................................................................... 13
3.4 Quantitative and qualitative approach ............................................................................ 14
3.4.1 Survey questionnaire design ............................................................................................... 14
3.4.2 Survey participants.............................................................................................................. 15
3.4.3 Interview questions design .................................................................................................. 18
3.4.4 Interview participants .......................................................................................................... 19
3.4.5 Data collection process ....................................................................................................... 20
3.4.6 Survey data analysis ............................................................................................................ 21
3.4.7 Interview data analysis ........................................................................................................ 22
3.4.8 Validating and piloting the study ........................................................................................ 22
3.5 Research quality ............................................................................................................. 23
3.5.1 Validity ............................................................................................................................... 23

III
 3.5.2 Reliability ............................................................................................................................ 23
3.5.3 Generalizability ................................................................................................................... 24
3.5.4 Ethics................................................................................................................................... 24
4. Results ................................................................................................................................... 25
4.1 Analysis of surveys ........................................................................................................ 25
4.1.1 Survey’s reliability analysis ................................................................................................ 25
4.1.2 Implementation of risk monument among respondents ...................................................... 25
4.1.3 Risk management to prevent projects failure ...................................................................... 26
4.1.4 Descriptive statistics & interpretation of hypotheses .......................................................... 26
4.1.5 Correlation analysis............................................................................................................. 32
4.2 Analysis of Interviews .................................................................................................... 33
4.2.1 Risks in software development ........................................................................................... 33
4.2.2 Success criteria’s in software development ........................................................................ 34
4.2.3 The relationship between risk management and project success ........................................ 34
4.2.4 Negative impact of risk management on project success .................................................... 36
5. Discussion .............................................................................................................................. 37
5.1 What are the risks in software development?................................................................. 37
5.2 What are the success criteria’s in software development? ............................................. 38
5.3 What is the relation between risk management and project success? ............................ 38
5.4 General discussion.......................................................................................................... 39
6. Conclusion ............................................................................................................................. 40
6.1 Contribution of the study................................................................................................ 40
6.2 Future research ............................................................................................................... 40
Appendix A – Survey questionnaire ............................................................................................. 41
Appendix B – descriptive statistics of surveys. ............................................................................ 43
Appendix C – Pearson Correlation ............................................................................................... 46
Appendix D – Interview questions ............................................................................................... 47
Appendix E – Interview Transcripts ............................................................................................. 49
Appendix F – Interview coding .................................................................................................... 66
References ..................................................................................................................................... 75

IV
Figures

Figure 2.1 Risk management steps in software project (Boehm, 1991) ......................................... 8
Figure 3.1 Distribution of our data sample with respect to company size.................................... 17
Figure 3.2 Distribution of survey’s participants with respect to their level of education ............. 17
Figure 3.3 Distribution of survey’s participants with respect to their role ................................... 18
Figure 4.1 Distribution of companies implementing RM in our dataset ...................................... 25
Figure 4.2 Respondents’ opinions on RM to prevent project failure ............................................ 26
Figure 4.3 Respondents’ opinions on RM to ensure meeting user requirements ......................... 27
Figure 4.4 Respondents’ opinions on RM to ensure completing the project ................................ 27
Figure 4.5 Respondents’ opinions on RM to ensure completing the project on budget ............... 28
Figure 4.6 Respondents’ opinions on RM to ensure completing on time ..................................... 29
Figure 4.7 Respondents’ opinions on RM to ensure having a high quality software ................... 29
Figure 4.8 Respondents’ opinions on RM to ensure that final system works as intended ........... 30
Figure 4.9 Respondents’ opinions on RM to ensure customer satisfaction .................................. 30

V
Tables

Table 2.1 Software projects risk factors (Hijazi, et al, 2014) ......................................................... 6
Table 2.2 A summary of former contribuations related to this study……….……….…………..11
Table 3.1 Survey questions, qnswer’s types & options given ...................................................... 14
Table 3.2 Nr. of responses with respect to their origin ................................................................. 16
Table 3.3 An example of the relation between interview and literature review questions ........... 19
Table 3.4 Main characteristics of our interviewees & type of the conducted interviews. ............ 20
Table 3.5 Used variables along with their types. .......................................................................... 22
Table 4.1 A summary of the statistical analysis performed on the tested hypotheses .................. 31
Table 5.1 Risks found through conducted survey and interviews ................................................ 37
Table 5.2 Success criteria based on the literature review and the gained results ......................... 38

VI
List of Abbreviations
MUR: Meeting User Requirements
FSI: Final System Works as Intended
CTP: Completing the Project
HQ: High Quality
CS: Customer Satisfaction
CPO: Completing the Project on Time
CPB: Completing the Project on Budget

VII
1. Introduction

1.1 Background
Software Development goes through a cycle of different phases. Software is planned, designed,
implemented, fixed and then released. In order to be able to use any software without any failures,
bugs, and errors software must be tested.

In 2015, the Chaos Report from the Standish Group reported that the success rate of worldwide
(fundamentally the US and Europe) was only 29%, while the other 71 % of projects have failed,
due to diverse reasons and risks (Vahidnia & Tanriöver, 2016).

Needless to say, failure in software development projects is not always related to bugs and
errors. Thus, in order to reduce the failure rate of software projects, field workers need to pay
attention to finance management, time management, unmet user requirements, as well as quality
management. Each of these areas appears as a risk if not managed in an adequate and suitable
manner (Kester, 2013).

In general, risk can be defined as a potential future loss or unwanted outcome that might arise
from some present action. However, according to (Hijazy et al., 2014) risks in software
development do appear due to items that present a threat to software project success. These items
are usually called software risk factors.

Thus, in order to lower the percentage of failure in software projects development, there is a
need to understand, identify, and manage the risks that might appear during the software
development process. Which is necessary to manage the underlying risks within the software
project (Samantra et al., 2016).

Further, risk management is defined as a process that starts with identifying, analyzing, and
managing threats to success and plan for necessary actions to minimize the chance of project
failure (Samantara et al. 2016).

1.2 Related work

Due to the high rate of software projects failure, researchers and field workers have always been
interested in finding the underlying reasons behind software failure. Thus, much research has been
done aiming to find satisfying answers, and possible solutions to minimize or hinder software
failure before occurring.

In their research, Arshad et al. (2007), have tried to identify the most important risk involved
in software projects in the public sector. Further, the study found that communications between
the different stakeholders are the significant factors that contributed to software project failure.

A few years later, Arnuphaptrairong (2011) argued that many researchers have tried to help
project managers to identify software projects’ risks, by providing a number of lists containing

1
most common risks. However, the author also claimed that it might be hard to know which list to
use. Thus, in order to solve this problem, he encouraged the organizations to develop their own
lists from their software projects experience.

Moreover, In a research conducted by Junior and Carvalho (2013) to study the impact of
software risk management on project performance in Brazilian companies, it has been found that
paying attention to uncertainties during the project, using risk management technique and deeply
understand the business environment are critical success factors for software projects. The study
also suggested that projects managers should assign a specialized professional to deal with risk
management practices.

In their study, (Hijazi et al. 2014) claimed that each phase of the Software Development Life
Cycle (SDLC) is vulnerable to several types of risks, their paper presents an overall theoretical
study of the key risk factors threaten each phase of the SDLC. They provide a list of 100 risk
factors that are common to most software development projects.

1.3 Problem formulation

Needless to say, risk is a part of all aspects of everyday life. Development of an informational
system is a complex process, which makes it submissive to a massive number of risks. As
mentioned earlier, many projects do not achieve previously set goals, or even they do fail. Thus,
risk management is not to be ignored in the development of informational systems.

Theoretically, it is well known that risk management is needed to handle and mitigate risks
within software development projects, and that is in order to ensure the success of the projects and
to avoid failure. However, it has been reported in the literature that some risk managements’
phases, risk identification phase in particular, have a negative effect on project success (de Bakker,
Boonstra & Wortmann, 2011), and that risk management as a process has its own risks
(Khatavakhotan & Ow, 2012). Thus, this makes it difficult to know whether risk management is
an effective solution for controlling and mitigating risks within the software development process.
I.e. it is unclear if risk management is related to software project success, and if so, then how is
that done in practice, or in other words; in which way does it do that.

1.4 Research questions

The research question suggested for this study is:

“What is the influence of software risk management on software project success?”

To get a comprehensive answer for the research question, we plan to answer the following sub
question:

1. What are the risks in software development?

2. What are the success criteria in software projects?

3. What is the relation between software risk management and software project success?

2
1.5 Purpose
The purpose of this research is twofold, academical and practical. From an academical point of
view, the purpose is to contribute to the body of knowledge, by clarifying how is project success
influenced by risk management, as well as to investigate on what has been indicated in former
studies about the negative impact of risk management, which could affect project success and lead
to failure (de Bakker, Boonstra and Wortmann, 2011), and to know more about the situations and
circumstances that led researchers to claim that risk management is a risky process by itself.

From a practical point of view, this study clarifies for companies, project managers, and field
workers the advantages of implementing a risk management process in their projects, and the
situations that should be avoided during that implementation, and that is by assessing the relation
between risk management and project success based on practitioners and project manager’s
opinions.

1.6 Delimitation

We decide in our research to limit our focus to IT projects that have software development as the
main concern, i.e. projects that are aimed at developing and implementing software systems, and
companies that have software development as core business. We also decide to limit our self to
small and medium-sized enterprises, or in other words; companies with less than 250 workers
(Growth, 2017).

1.7 Target group

We hope that our research results will prove useful to a large audience in software development
including Developers, Testers, Software Architects, Project Managers, IT Consultants,
Researchers, Sales Representatives, Business Owners, and of course Customers or Product Owners
when discussing project risks and the risk management process.

1.8 Outline
Section 2 - Represents the theories that our research is based on.

Section 3 - Describes in details the approach and the steps taken to perform this research, and to
analysis methods the collected data.

Section 4 - Shows the results of this research

Section 5 - A discussion of our findings and whether our research questions were answered or not

Section 6 - A Conclusion where we wrap up the thesis by giving a final conclusion and suggestions
for any future work.

3
1. Literature Review
This Chapter presents the literature and theories reviewed. As this study examines many variables,
a funnel structure is used, i.e. the discussion of the topic starts out in general terms, and the
progressively narrow to become closer and closer to the purpose of our study. The review of
literature generates a theoretical framework that guides the data collection.

2.1 Software development life cycle

Software development process or system development life cycle is a structure followed by
developers within software development companies. Hijazi et al. (2014) defined SDLC as a
structure imposed on the development of software projects and contains six phases, each one of
them produces deliverables required by the next phase. All software project must go through these
six phases, which according to the authors are:

 Requirements analysis: where all the project’s requirements are gathered and the system
service, objectives, and constraints are defined. A requirement specification document is
created to be used in the next phase.
 Design phase: in this phase the overall system architecture is established, all the
requirements defined in the previous phase must be addressed.
 Implementation/Coding: the actual development of the software starts in this phase, it is
the main focus for the developers, since the code is produced in this phase. In this phase
each source code modules is tested to ensure that each module meets its characterizations
and accomplishes what it is supposed to do, before they are integrated and tested as a whole
system.
 Testing phase: after the code is developed, it is tested to make sure that the product meets
the requirements gathered in the first phase.
 Deployment Phase: the product is delivered to the customer, and tested for user acceptance.
 Maintenance phase: the last phase in the process. The customer starts to use the system and
problems start to show up, and must be resolved. This phase may involve repeating the
former phases.

Further, in order to control the software development process, a software development

methodology which is a framework that includes techniques, procedures, and tools to help
developers in their task is used. The following are examples of common software development
methodologies.

The waterfall model is a linear design process. The model begins with establishing system
requirements and continues with design, coding, testing, and maintenance. The action in each
phase relies on the action of the previous phase. Therefore, the process cannot move to the next
phase unless finished with the current phase Waterfall model should be followed when the
requirements of the project are clear, and when the changes are stable (Ali Munassar & Govardhan,
2010).

The V-model (Verification and Validation model). Same as waterfall model, it is sequential
model, and each phase must be completed before the next phase begins. Each phase is directly

4
connected to a validation phase (testing phase). This model is suitable when requirements are clear,
there are no fuzzy or ambiguous requirements, and when the project is short (Ali Munassar &
Govardhan, 2010).

Agile method is a compound of iterative and incremental process model, which divides the
development process into small iterative and incremental blocks. The product is tested
continuously, through the delivered iterations, mitigating the risk of any failure in the future
(ENFEI, 2015).

The spiral model is a combination of waterfall and prototyping models (iterative and sequential
linear model), with focus on risk analysis. This model consists of four phases: Planning phase: in
this phase, requirements are collected and risk is assessed. Risk analysis phase: a process starts to
identify risk and alternative solutions. Engineering phase: software is produced along with testing
at the end of the phase. Evaluation phase: the customer evaluates the project before moving to the
next spiral. (Ali Munassar & Govardhan, 2010).

2.2 Software development risks

All types of projects have constraints and/or limited by many things; human and economic
resources, quality, and time, among others. However, the risk constraint in software development
projects, is of a great importance, as software and by its ethereal nature is riskier business (Lewin,
2007).

Project risk is “an uncertain event or condition that, if it occurs, has a positive or negative effect
on one or more project objectives such as scope, schedule, cost, or quality” (Muriana & Vizzini,
2017). Generally, there are two types of risk, namely: dynamic and static risk (Esiefarienrhe,
2015). However, software risks are considered to be dynamic, as they have aspects of both gain
and loss associated with them, as well as that their impact typically does vary with time and
circumstances (Esiefarienrhe, 2015).

Hijazi et al. (2014) have described software development risks as the items that form a threat
to software project success, which are usually called software risk factors (Bannerman, 2008).
Those factors could be technical, economical, and behavioral in nature (Barki et al., 1993).
Environmental factors, refers to the factors that are related to the environment where the software
will be implemented and used in (Gupta & Sadiq, 2008). While managerial factors are related to
the management of people, time and budget. Organizational factors on the other hand, are related
to the organization that has developed the software and it is organizational environment
(Sommerville, 2016). Yet, technical factors which are the results of the improper usage of software
engineering theories and software/hardware technologies (Dhlamini et al. 2009; Sommerville,
2016), appear to lie at the center of many software failure reasons (Hijazi et al. 2014).

Further, Vahidnia and Tanriöver (2016) identified 128 risk factors based on software
practitioner’s experiences, which includes the following risks: Lack of training of the team, lack
of project management experience, bad project management approach, and expansion of software
requirements.

5
 However, each cycle of the SDLC is vulnerable to several types of risks. The authors conducted
another research within the same year, where they provide a list of 100 risks factors associated
with each phase (Hijazi et al., 2014). Table 2.1 shows the risks associated with each phase of the
development life cycle.

Table 1.1 Software projects risk factors (Hijazi et al. 2014)

6
2.3 Software risk management
The increasing demand on software and IT solutions, as well as the expectations of the customer’s
requirements, creates a competition within the software development market, which in turns,
forces development companies to manage their projects' risks carefully, this forms a challenge for
software development organizations, which concerns dealing with risk projects and improving the
success-to-failure ratio (Wanderley et al., 2015).

Risk management is all about perception and detection of sources of risks through the different
phases of the project. Generally, the success of many organizations is becoming more and more
dependent on the success or failure of the software they build. Thus, managing risks is not only a
typical process; rather it is a vital business practice (Hall, 1998; Murthi, 2002).

The practice of risk management, can either be reactive or proactive. Within the reactive
approaches, risks are not mitigated until they occur. In the proactive approaches, however, risk
occurrences’ are being avoided. Needless to say, it is favorable to avoid risks rather than repairing
and handling their consequences (Singh & Goel, 2007).

Moreover, due to the fact that the development of an informational system is a complex
process, which makes it compliant to a significant number of risk, researchers have since decades
ago been interested to study those risks and how do they affect the process of software development
(Abe et al, 1979).

However, it has been indicated that risk management in software projects did not receive a
sufficient attention. Dedolph (2003) explained the reason behind that which is related to the
difficulty of risk management assessment, the shortage of resources, the need for structural
changes, and that companies and organizations are resistant to change their ways and policies to
follow risk management. In spite of the inattention in industry, there is a large number of academic
works within this area, without forgetting the masterpiece “Software Risk Management” (Boehm,
1989) which has been highly cited over the years.

Risk in software projects development has been defined several times. Yet, the most prevalent
definition is in terms of exposure to specific factors that might form a threat to achieving the final
outcomes of a project (Bannerman, 2008). Those factors could be technical, economical, and
behavioral in nature (Barki et al., 1993). Software Risk Management refers to a series of steps
whose objectives are to identify, address, and eliminate software risk items before they become
either threats to successful software operation or a major source of expensive rework (Boehm,
1989). As shown in figure 2.1, Boehm (1991) explains the two main steps that are involved in risk
management, risk assessment and risk control, each of them involves three sub-steps.

7
 Risk Identification

Risk Management
Risk Assessment Risk Analysis

Risk Prioritization

Risk Planning

Risk Control Risk Resoluation

Risk Monitoring

Figure 1.1 Risk management steps in software projects (Boehm, 1991)

Risk assessment starts with risk identification, which aims to create a list of risk factors and
categorize them into different categories. Risk identification is then followed by risk analysis,
which aims to calculate and estimate the probability and the dimension of the identified risk items.
Risk prioritization is where the analyzed risks get ranked. After completing the risk assessment,
the next step will be risk control. Risk control starts with risk planning, which aims to plan how to
deal with the different risk factors. After planning, it is the turn for risk resolution, where actions
and methods will be implemented to control risk factors. The final sub-step in risk control is risk
monitoring, where resolving risk factors will be tracked (Boehm, 1991).

As seen earlier, to manage risk factors, studies over the last three decades have suggested a
diversity of methods, approaches, process, and models (Janjua et al. 2016). Which is supposed to
be used to increase the success rate, and reduce the failure of software project development (Janjua,
2016). Further, the use of risk management in projects related to successful projects can be seen
in several studies. Zwikael and Ahn (2011), conducted a research across three different countries
(Israel, New Zealand, and Japan). The results indicate that risk management has a relation with
project success. DIDRAGA (2013) emphasized in his research on the role of risk management as
a contributor to project success. Moreover, According to project management theory (Pinto, 2007;
Turner, 1993), project risk management has a positive effect on project success in terms of “on
time, within budget” delivery of a pre-defined result.

Nevertheless, the literature reported some skeptical opinions. Bakker, Boonstra, and
Wortmann (2011) found some indications that risk management, particularly risk identification,
led to a negative effect on project success. Further, research show that even risk management
process faces some risks (Khatavakhotan & Ow, 2012). It has also been indicated that the
development of risk and risk management in the literature, lacks the needs of the phenomenon in
practice, and that adoption of risk concepts and risk management methods in practice lacks the
understandings and prescriptions found in the literature (Bannerman, 2008). This, makes us
wonder and ask the following questions: is and how risk management related to software project
success in practice?.

8
2.4 Software projects between success and failure
In their book, Sodho and Sodho (2001), mentioned some of the characteristics of a well-managed,
successful IT project, which include: satisfaction of the stockholders, satisfaction of team
members, fewer bugs existing in the system, technically well-handled, meeting the schedule,
completing the project within budget and time, and a well documentation of the project.

Success in projects have two different aspects. Project success, which is related to the
judgments of the outcomes of the project, and project management success which concerns the
successful delivery of a project (Cook-Davies, 2002). However, this does not mean that those two
aspects should be met to say that a project has succeeded. For example, a project could be
considered as a well-managed project, but still fail to deliver the required functionality, while a
poorly-managed project, could still be capable to deliver and function successfully (Jugdev et al.
2013).

In their Chaos Report (1995), the Standish Group classified projects into three different types,
depending on their level of success.

Type 1: project succeeded; i.e. the project was completed within time and budget with all features
working as intended.

Type 2: project challenged; in this case, project was completed, but with a time or cost overrun,
and/or lacking some of the specified features.

Type 3: project failed: the project in this case was neglected or cancelled for some reason, and
thus, all investment were lost.

Spector and Gifford (1986), compared software development to bridge building. The primes
say: bridges are usually built on-time, on-budget and do not fall down. On the contrary, software
never comes in on-time or on-budget, and it always breaks down (Spector and Gifford, 1986).

Anil and Thomasson (1991), identified four factors that that almost ensures a bad outcome:
poor internal communication, poor external communication, absence of responsive decision
making, and absence of an effective teamwork.

Frese and Suater (2014) have listed a list of factors that were found in failed projects, the list
includes: incomplete requirements, poor user involvement, resources deficiency, impractical
expectations, missing executive support, continues changes in requirements, and improper
planning.

On the other hand, factors that lead to project success have been identified differently by
different contributions. User involvement, executive management support, and clear requirements,
are according to (Shane Hastie & Wojewoda, 2015) three major factors that lead to project success.
Frese and Sauter (2014), mentioned five factors that are considered to be essential to software
projects success: user participation, management support, clear requirements, proper planning, and
reasonable expectations. Those factors if done properly, the project will have a better chances for
success (Frese & Sauter, 2014).

9
 However, despite that factors that lead to project success or failure have been discussed
thoroughly in the literature, there are neither stock answers nor silver bullets that will guarantee
success. Software projects are naturally considered to be complex. Thus, each new project is
different from anything observed earlier; as the technology differs, the team differs, the company
climate differs, and the intent of the project differs. Each of these differences creates stresses on
the project success. (Frese & Sauter, 2014).

2.5 Software risk management and software project success

Despite that software is contributing to a large portion of our daily life and within a variety of
areas, software development projects are known for failure (Savolainen et al., 2012). Further,
researchers have been wondering whether we have learned enough to ensure that our software
developments projects are successful (Cerpa & Verner, 2009). Bakker et al. (2011) claimed that
project success is an objectively measurable state, which can describe how well the project
performed in relation to success indicators, time, budget, and requirements.

Nevertheless, it is not enough for organizations and industries in the current decade to consider
a project that has been completed upon the estimated time and budget while meeting all users’
requirements, as a successful project (Khan & Ghayyur, 2010). Therefore, considering the various
levels of software project risks that are associated with software development is a must. As those
levels, might hinder the project from a successful completion (Khan & Ghayyur, 2010). Thus,
managing risks in software development is not an option, rather than a necessity per se (Tao, 2008).

Choosing an appropriate model for risk management is seen to be one of the most important
duties that are assigned to the project manager. As any neglecting in dealing with risks properly
will increase the chances of project failure (Hashimi et al., 2012). Thus, such a choice must be
made carefully, matching the size of the development team, the level of complexity of the tasks,
and the leadership of the development team (Gallagher, 2002).

De Wet and Visser (2013), found in their study, that wherever risk management is applied,
software projects produce better results. Bannerman (2008), claims that risk management can lead
to a variety of project and organizational benefits including: identification for better alternatives
actions, increased confidence in reaching project goals, better chances of success, reduced
surprises, better and precise estimations, and less duplication of efforts.

However, Janjua et el. (2016) indicates that to measure the effectiveness of risk management,
it must be viewed in broader context of project success. Thus, this suggests taking a wider
perspective for projects success, which according to the literature includes the following items:

 Meeting user’s requirements (Boehm, 1989; McConnell, 1996; Procaccino et al., 2005).
 Completing the project within budget (McConnell, 1996; Linberg, 1999: Procaccino et al.,
2005).
 Completing the project on time (McConnell, 1996; Linberg, 1999).
 Completing the project (i.e. project was not cancelled) (Linberg, 1999).
 High quality system, i.e., having a solid and well tested system (Linberg, 1999).
 Customer satisfaction (Procaccino and Verner, 2009).

10
2.6 Summary of literature review

To sum up, from the conducted literature review, we have figured out that software risk
management plays a major role in projects success. As it helps in identifying, analyzing, and
mitigating risks and risk factors before they turn in into problems. Thus, grounded on previous
researche, we can theoretically say that risk management is important for ensuring success in
software development.

However, it has been found that literature lacks information about the relation between risk
management and software project success in practice, as some research categorized risk
management as a risky process, and that in some cases it could even lead to failure. While other
research suggested that in order to understand the influence of risk management on project success,
project success should be considered in a wider perspective. The following table summarizes the
former contributions along with their theoretical foundations, in which this research is based on.
Authors Publication Title Theoretical foundation
Janjua, U., Jaafar, J. and Lai, Expert's opinions on To measure the effectiveness of risk
F. (2016) software project management, it must be viewed in
effective risk broader context of project success.
management
Khatavakhotan and Ow. Rethinking the Risk management is not a risk free
(2012). Mitigation Phase in process.
Software Risk
Management
Process: A Case
Study
de Bakker, K., Boonstra, A. Risk managements' “This research found some interesting
and Wortmann, H. (2011). communicative indications that risk management, in
effects influencing particular risk identification in which
experts participate, led to a negative
IT project success
effect on project success. New research
could focus particularly on the question
under which conditions and how risk
management
contributes to project failure.”
Bannerman, PL (2008) Risk and risk Risk and risk management in literature
management in lacks the needs of the phenomenon in
software projects: A practice, while risk management
methods in practice lacks the
reassessment
understandings and prescriptions found
in the literature

Table 1.2 A summary of former contributions related to this study

11
2. Methodology
In this chapter, a detailed description of the followed research approach is given. For this study, we used
mixed methods: a survey followed by semi-structured interviews. This section starts with a method
description, followed by a description of the conducted literature review, an introduction to the tools
used for data collection, and description of the sample population for both the survey and the
interviews is provided. Then we continue describing the steps performed for data analysis. Finally,
we discuss the validity and reliability, as well as the measures taken to ensure our research quality.

3.1 Method description

Each scientific research is classified depending on its purpose. There are types of research:
exploratory, explanatory, and descriptive (Bhattacherjee, 2012). Further, various types of research
could be used to answer a specific research question (Recker, 2013). However, taking into the
considerations the purpose of this study, which is to find the influence of software risk management
on software project success, and whether software risk management contributes to software project
success. Considering the previous definitions, as well as our research questions we realize that our
study is suitable to be performed using an explanatory research. Especially that explanatory
research’s goal is to provide an answer concerning the casual mechanisms of a phenomenon
(Recker, 2013), and to explain the relation between different variables (Saunders et al., 2007).

3.2 Research approach

Every scientific research has two levels, a theoretical level and an empirical level (Bhattacherjee,
2012). Further, the theoretical concepts are tested in order to build better theories in the empirical
level. This can be done using one or more of the following approaches: inductive, deductive, and
abductive (Recker, 2013).

Inductive reasoning refers to the movement from a set of specific facts towards a general
conclusion, while deductive refers to deriving arguments as logical consequences from a set of
assumptions (Recker, 2013). The inductive and the deductive approaches are called as “theory
building” and “theory testing” respectively (Bhattacherjee, 2012). Further, the deductive approach
is concerned with developing a theory based on a number of hypotheses followed by a rigorous
test (Saunders et al., 2007). Last but not least, the third approach which is called abductive
reasoning, is used when the researcher suspect that some unrelated facts are somehow connected
to each other (Recker, 2013).

Taking into considerations the definitions above, as well as the purpose of this study, this study
applies a deductive research, since it tests a previously developed theory, by testing seven
hypotheses about the influence of software risk management on software project success.

Further, for this study we use a mixed methods approach; a survey followed by semi-structured
interviews. As that Mixed method approach encourages a stronger inference, provides a greater
diversity of forked views, and helps in verifying and generating theory at the same time (Reker,
2013).

12
3.3 Literature review

3.3.1 Description of the literature review

In order to build a theory to be tested in this study, a comprehensive literature review has been
done, through identifying, critically analyzing, and integrating the results and the findings of
previously conducted studies. Aiming to gain a holistic overview, and an insight into the relevant
used, theories, and research methods in this context. This helps in identifying relations,
contradictions, gaps, as well as the inconsistencies in the literature (Baumeister & Leary, 1997).

Literature related to the software development, software risks, software risk managment, and
software project success contexts were studied, particularly those concerning the definitions,
developments, characteristics as well as benefits, opportunities and threats to those concepts. As
peer-reviewed articles and book chapters represent the suitable data resources (Wolfswinkel,
Furtmueller & Wilderom, 2013), the review was mainly focused on this kind of literature. Thus,
the review was conducted using Lund University library search, ScienceDirect, SpringerLink,
EBSCOhost, and Google scholar as sources for finding the literature references. Further, several
keywords were used in this study including software risk management, software risk, software
project success.

In addition to all of that, further literature was taken into the consideration, and that is according
to the snowball principle, as many authors claim that it represents an “effective tool” (Atkinson &
Flint, 2001; Palinkas, Horwitz, Green, Wisdom, Duan & Hoagwood, 2015; Waters, 2015). Thus,
it is widely used for gathering the relevant information of a specific topic and to identify the
different contributions within a specific area of research (Bryman & Bell, 2015). The snowball
principle means that the references that appeared to be important and were used by the authors of
the selected articles and books, were reviewed during the literature review. The results of this
literature review are presented in chapter two, and were used to build a frame of references for this
study, as well as to help in answering the research questions.

3.3.2 Validity of the literature review

To ensure that the conducted literature review is comprehensive and that it contains multiple
perspectives, a mixture of different kinds of literature were reviewed, such as books, case studies,
journal articles, and conference proceedings. That has been done using several research engines,
and through reviewing contributions from various countries with a broad variety of publication
dates.

Further, the snowball principle was used here to identify important contributions, get additional
references, and gain a better knowledge within the area. To enhance the reliability of this approach,
we describe and document all procedures, findings, and the underlying reasoning. Moreover, the
relevant contributions were electronically stored, and that is to ensure a permanent access.

13
3.4 Quantitative and qualitative approach
In order to be able to collect a decent amount of data within a short period of time, and with a
minimal cost, survey method would be a suitable choice (Bhattacherjee, 2012), this has also been
applied here. However, surveys can be conducted using one or more of the following approaches:
postal questionnaire, internet survey, and face-to-face interviews, telephone interviews (Robson,
2011). Thus, considering the characteristics of each approach, as well as the limitations in time
and cost, and most importantly the purpose of this paper, internet survey is used.

3.4.1 Survey questionnaire design

Our questionnaire consists of four different parts. The first one contains an introduction where we
describe the purpose of the research, thank the respondent for his/her participation, as well as
ensuring to the respondents that their responses and all information obtained in connection with
this study will remain confidential.

The second part of the questionnaire contains a demographic information on the respondent’s,
such as country working in, company’s name (optional), number of workers at the company,
position, years of experience, as well as their level of education. Table 3.1 shows questions along
with their answer’s type, as well as the options that were given to the respondents to choose
between.

Question Answer’s Type Options

Country working in Short answer text -----------
Company’s Name (optional) Short answer text -----------
Number of Workers Multiple choice 1-49, 50-99, 100-149, 150-
199, 200-250.
Position Multiple Choice Project manager, developer,
tester.
Years of experience Multiple choice 0-3, 4-7, more than 7.
Level of education Multiple choice High school, Bachelor,
Masters, Ph.D.

Table 2.1 Survey Questions, Answer’s Types & Options given

On the last for questions of this part, namely numbers of workers, position, years of experience,
and level of education, the respondents were provided with an extra option, which is “other? Please
specify:” where the respondent is given the possibility to fill in their data, in case if not listed
among the given options.

The third part of the questionnaire includes questions on the influence of software risk
management on software project success. This part starts by asking the respondent whether there

14
current company do implement any kind of risk management process or not, followed by a question
to see whether software risk management prevent software project failure. Each of those questions
has two possible answers, namely “Yes” and “No”. The questions were followed by seven
questions (the hypotheses to be tested), to check whether software risk management contribute to
the project success criteria’s that were identified in our literature review, which are: meeting user
requirements, completing the project (i.e. project was not cancelled), completing the project within
budget, completing the project on time, high quality software (having a sold and well tested
system), final system works as intended, and customer satisfaction. Those were measured using a
five point Likert Scale ranging between 1 (“Strongly Disagree”) to 5 (“Strongly agree”). The Likert
scale is one of the well-known rating scales to measure such kind of ordinal (Bhattacherjee, 2012).

In brief, this part of the questionnaire tests the following hypotheses (based on the conducted
literature review):

H1: Software risk management ensures meeting user requirements.

H2: Software risk management ensures completing the project within budget.

H3: Software risk management ensures completing the project on time.

H4: Software risk management ensures completing the project (i.e. project was not cancelled).

H5: Software risk management ensures stability and reliability of the system.

H6: Software risk management ensures that final system works as intended.

H7: Software risk management ensures customer satisfaction.

The fourth and last part of questionnaire, contains two more questions. The first one, is to
investigate, whether all projects require a risk management processes. Here the respondent was
provided with two answers “yes” and “no”, and if no, the respondent has the option to provide
examples of projects that do not require a risk management process. The second question, which
is also optional asks the respondent to give examples of risks that lead to project failure.

3.4.2 Survey participants

Surveys can be categorized into self-administrated and interviewer-administrated surveys

(Saunders et al., 2007). Participants in the self-administrated surveys, can choose the
circumstances freely in which they want to respond to the survey. Web and postal surveys are two
examples of self-administrated questionnaires. On the other hand, in interviewer-administrated
surveys, an interviewer is posing the questions to the interviewee, either face-to-face, on the
telephone, or possibly using a video chatting program.

Nevertheless, for this part of this study, and as mentioned earlier, we chose web surveys. As it
is easy to distribute by nature and as it consumes less time and cost for the administration in
comparison with the other alternatives. In addition to all of that, the results are already available
in a digital format, which eases the preparation for the quantitative analysis. Google Form is used
to administrate the survey, as it is free of charge and provides a diversity of useful functionalities.

15
It also provides basic descriptive statistics and graphics to get a sense of the received data. Further,
it provides the responses in a spreadsheet format, with the rating degree question already coded as
numbers. Needless to say, sharing an online questionnaire is convenient, as it only requires copying
the URL and sending it via e-mail to the respondents.

The survey was sent to approximately 430 companies, it has also been shared within our
network of friends who are working within the field, and they in turn where asked to forward it to
their colleagues. Totally, we received 121 answers, thus scoring 28% response rate. Approximately
ten days were given to companies to respond before collecting the data and starting the analysis
phase. However, out of 121 responses, 5 were not suitable for our research due to several reasons,
which are explained in details in section 3.5.2.

As a result of having a web survey, we were able to reach field workers working overseas, and
thus receive responses from 21 different countries, located in four continents: Africa, Asia, Europe,
and South America. Table 3.2 shows the number of received responses from each country in our
data set.

Country Nr. Of Received Responses For Each Country

Sweden 46
Bulgaria 12
Syria 7
Egypt 6
Iran 5
Greece – India – Turkey 4
Saudi Arabia – Jordan 3
Austria – Bolivia - China – Colombia 2
– Czech Republic – Ghana – Lebanon
– Pakistan – Qatar – Sudan –
Switzerland
Table 2.2 Nr. of responses with respect to their origin

As our research concerns small to mediums-sized software developing companies, i.e.

companies with up to 250 workers, 74 answers were received from companies with up to 49
workers, 10 from companies with 50-99 workers, 2 from companies with 100-149 workers, and
30 answers from companies with 200-250 workers. Figure 3.1 shows the distribution of the
obtained answers with respect to company size.

16
 Nr. Of Recieved Answers

Figure 2.1 - Distribution of our data sample with respect to company Size

Further, our dataset shows that the majority of the participants are holders of an academic
degree. Out of 116 valid responses, 68 responses were received from a master degree holders,
forming 58.6% of the total responses. 42 responses from participants holding a Bachelor degree,
and 2 responses from a PhD holders participants, as well as 2 responses from participants with no
academic degree. Figure 3.2 shows the distribution of the participants with respect to their level of
education.

Figure 2.2 Distribution of survey’s participants with respect to their level of education

17
 Moreover, as our research concerns IT companies having software development as a core
business, our dataset contains responses from developers, testers, and project managers only, with
66 responses from developers, 38 from project managers / leaders, and 12 from testers. The
following figure shows the distribution of our participants with respect to their roles.

Figure 2.3 Distribution of survey’s participants with respect to their role

3.4.3 Interview questions design

After conducting the survey, four semi-structured follow-up interviews with three project
managers and a CTO were conducted, in order to learn more about their insights as project
managers and decision makers on software risk management in relation to project success. The
main purpose of the interviews is to get a deeper understanding on the subject and an answer of
our research questions. The interview questions, were based on our findings in the literature
review. Table 3.3 shows an example of how our interview questions are related to our research
questions, as well as to the literature. In addition to all of that, complementary questions were
asked during the interview for a better understanding. A full copy of our interview is attached in
Appendix D.

18
 Research Questions Examples of the Related Literature
 What are the success criteria  Does Risk Management Contribute to
in software projects? IT Project Success? (Bakker,
 What is the influence of Boonstra & Wortmann, 2009).
software risk management  Rethinking the Mitigation Phase in
on software project success? Software Risk Management Process
(Khatavakhotan & Ow, 2012)

Related Interview Questions :

 How do you define a successful project? From your definition to project
success, do you think that risk management contribute to project success?
How?
 In your opinion, does software risk management prevent software failure? If
yes, then how?
 Some research shows that software research management has a negative
impact on project success, is that possible? In which situations?
Examples of Complementary Questions (See Appendix D):

• How do you define a successful project? I.e. what are the key characteristics of a
successful project?
• How do you define software development risk? Please give examples of
software development risks that could lead to software project failure?
• On a scale between 1 to 5, where 1 is “Strongly disagree” and 5 is (“Strongly
agree”), does software risk management ensure meeting the following project
success criteria’s: Meeting user requirements?, Completing the project on
time?, etc.
• Please describe how does risk management contribute to the project success
criteria’s you agreed on?

Table 2.3 An example of the relation between interview and literature review questions

3.4.4 Interview participants

To get a better understanding of the problem, we interviewed three project managers/leaders and
a CTO, to hear their opinions in details on the problem, and to get a clear answer to fill the gaps
that were identified during the literature review. Table 3.4 shows the main characteristics of our
participants, their role, years of experience, etc.

19
 Interviewee 1 Interviewee 2 Interviewee 3 Interviwee 4
Role Project Manager CTO Project Leader Project
Manager
Years of 15 8 1 15
experience
Level of Bachelor PhD Bachelor College
education Degree
Company’s Riyadh Saudi Arabia, Växjö Sweden Jönköping Stockholm
location Cairo Egypt Sweden Sweden
Nr. or workers 150 25 6 215

Type of interview Phone Call In person Skype Phone Call

Transcription Appendix E Appendix E Appendix E Appendix E

(Table E.1) (Table E.2) (Table E.3) (Table E.4)

Table 2.4 Main characteristics of our interviewees & type of the conducted interviews.

3.4.5 Data collection process

In order to do a comprehensive and an inclusive study that many others can relate to, it is suitable
to perform a quantitative study (Recker, 2013). Thus, after conducting the literature review, and
order to investigate and to get a clear understanding on which influence has risk management on
project success, we decided to start our study with a survey.

Initially, our targeted companies, were found using LinkedIn (LinkedIn, n.d.) research
function, by typing “software development” in the research field, and then filtering the results to
include only companies. The research result includes the companies’ names, and the number of
their employees. From there, we took each company’s’ name and searched for it in google, after
that we emailed the surveys’ link to them using their contact email. For companies in Sweden, we
have even phoned them to clarify our purpose, and to ensure a better participation’s rate.

As mentioned earlier, after collecting and analyzing the results of the survey, two follow-up
interviews were conducted. The main purpose of these interviews is to confirm, relate, and/or
compare the quantitative and the qualitative data, as well as to gain an in-depth understanding of
the problem, which in turn will help in getting answers for some of the research questions, that
needs to have open-ended questions, which could be hard to do throw a self-administrated survey.

The interviews were semi-structured, of which one was conducted in person, while the second
interview has been conducted through a phone call. We have asked the second interviewee to
conduct the interview through a Skype video call, so that we can see his facial expressions and
read his body language. However, he refused the idea of having a video call for some reason. Thus,
we had no choice rather than respecting his decision.

20
 Nevertheless, both interviews had a length varying from 14 to 20 minutes, which can be seen
as a short time span. This can be explained by the quite specific focus of our questions, which
appeared to be clear to them, especially that they seemed to be very informed on the discussed
topic, and were able to give straight-forward answers. Further, we were able to deliver and forward
our questions in specific direction, as we already have gained important information from our
survey’s result. Yet, the interviews did support and help us enriching our research with a deeper
understanding for software risk management role in software project success, as well as providing
us with examples on how risk management can lead to failure if not done properly.

In brief, this study has followed a combined quantitative and qualitative approach. Thus, we
have two different types of collected data that have been analyzed in different ways. The analysis
of both types of data is described below.

3.4.6 Survey data analysis

The main purpose of the survey was to gain on overview of the influence of risk management on
project success, based on practitioner’s experiences and opinions. As a first step while collecting
data, a cleansing check was performed to exclude irrelative answers. This included removing
answers from non-field workers, which included two answers from a business analyst and a
network administrator. Also, as our research concerns software development companies, i.e.
companies that has software development as a core business, three answers that have been received
from a telecommunication company, a bank, and an energy company were excluded.

Further, we checked the entered data for typing mistakes, especially on country names, so that
they become consistent throughout the whole survey. An example of the data cleansing in this step
is correcting entries like “sverige” to “Sweden”, “Syrian Arab Republic” to “Syria”, and “misr”
which refers to Egypt in Arabic, to “Egypt”.

After ensuring that our data were clean, and in order to approach some of the primary research
questions of this study, a “survey analysis” has been done. Needless to say, survey analysis is best
for testing the proposed hypotheses, as it is useful for testing the relationship between the
dependent variable “software success criteria’s”, and the independent variable “software risk
management” to figure out the relation between software risk management and project success.

The analysis has been done using two different software. First, Qlik Sense. Qlik Sense is one
of the many software packages used to perform data analysis in uploaded datasets (Qlik.com, n.d.).
We used it in our research to present a descriptive statistics result of respondent’s demographics,
as it provides a rich graphics that help in visualizing the results.

Further, IBM SPSS has also been used to analyze the received survey answers. This has been
done by performing descriptive analysis on each criteria of project success criteria’s that have been
discussed earlier, to see how they are affected by risk management.

Moreover, Pearson’s correlation has been used to test the proposed hypotheses. In short, for
testing the hypotheses, correlations between different project success criteria’s affected by risk
management, to investigate whether they lead for each other.

21
 However, in order to be able to work in SPSS, different items must be coded into variables.
Thus, we got 18 different variables in total. Table 3.5 illustrates the used variables in our study,
along with their types.

Table 2.5 Used variables along with their types.

3.4.7 Interview data analysis

During this phase of the study, and as starting step, interview data was transcribed into text for
further analysis. The text was then analyzed through coding, which is described by Recker (2013,
p.92) as “assigning tags or labels as units of meaning to pieces or chunks of data collected –
words, phrases, paragraphs or entire documents”. This has been done using NVivo, which is a
software used for analyzing unstructured data like interview transcripts (QSTInternationaöPtyLtd,
2017), by breaking the data into fragments and then putting those fragments into categories and
subcategories if needed. The used categories and subcategories for the interview transcripts for
this study included information behind project success, project failure, role of risk management in
software development, and different perceptions on risk management. The interviews were then
analyzed based on those categories.

3.4.8 Validating and piloting the study

Piloting and validating the questionnaire are very important for the validity of this study. Survey’s
questionnaire was inspected by our supervisor, as well as friends working in the field. This has
revealed several issues; the lengths of the questionnaire, the redundancy of questions and the
general format of the survey. The survey was then enhanced and adjusted according to the received
comments, and that is before the questionnaire were administrated.

The questionnaire was also tested by a three of our friends working in the field, they filled in
the questionnaire and were then asked by the researchers for their opinions and suggestions
regarding the wording, order of questions, and the format of the survey, and that is to ensure a
better quality of the questionnaire. Some questions were changed for a simpler language to be

22
more understandable by the respondents, other questions were dropped as they seemed redundant,
and one question that seemed to be valuable to our research was added.

Interview questions were also validated and piloted, by simulating and performing the
interviews with two friends working as developers, to see whether our questions are
understandable to them or not. According to their opinions, the questions were reordered and
reworded in a way that serves the purpose of this study.

3.5 Research quality

In order to ensure the quality and trustworthiness of our research, quality was taken into
consideration with each step taken in our study. Thus, our main principle throughout the entire
process was to stay sure of every single stated action in the research method above, and to explain
each step in details. In the following sections we explain in details measure taken for validity,
reliability, generalizability, as well as the ethical aspects of our study.

3.5.1 Validity

Validity refers to the validity of the collected data and its analysis, as well as the data represents
and measures what it is supposed to (Recker, 2013). Some guidelines were followed to choose our
sample population, as to select participants based on their relation to the field and the size of
company’s they working at. Thus, assuring our intent for having field workers, working in small
and mid-sized companies is transparently presented.

By performing the data cleansing described in section (3.4.6) we made sure that no irrelative
responses would be considered and influence our final findings.

Further, before performing the interviews, we selected our participants based on the conducted
literature review, so that more knowledge could be generated to fill the gaps found while reviewing
the literature. Thus, interviewing those responsible for performing risk management in software
development, so that they enrich our research with their experience. Moreover, after compiling the
transcribed interviews, we double checked by the person who did not transcribe the original
interview to ensure that no errors or misunderstanding exists.

3.5.2 Reliability

Unquestionably, the reliability of a research is very important as it ensures that the operation of a
study – such as the data collection and data analyzing procedures - are reliable and real to the
underlying environment, and thus can be repeated at any time yielding the same results
(Bhattacherjee, 2012). For the data collection, field workers were surveyed directly; data was not
collected from secondary sources. Further, to make sure that respondent have what is needed to
participate in the study, we ask them to specify their role, and the size of company they are working
at.

23
 Moreover, we contacted our potential interviewees in advance, and clarified our purpose of the
study, we then asked them to see whether they agree on the interview procedure or not. Thus,
making sure that voluntary participation as suggested by Bhattacherjee (2012) is achieved.

3.5.3 Generalizability

To ensure external validity which is needed to guarantee some level of generalizability of our
findings (Bhattacherjee, 2012), we explain and demonstrate as much details as possible on how
and what criteria were used to select respondents. We made sure that our study includes responses
from workers in different countries, by sending our survey and contacting companies in different
world parts, so that the results are widely applicable as possible. However, as we stated earlier, our
survey concerns small and med-sized software development companies (companies having
software development as a core business), so we do not really know, whether our results are
applicable on big companies, or companies having software development as a part of their business
only.

3.5.4 Ethics

Ethical behavior from the researcher’s side, and producing an ethical research in general was taken
into considerations through the whole study, by following literature suggestions regarding this
matter.

While conducting the surveys, we informed participants on their anonymous treatments and
the confidentiality of their data during analysis, and that no data would be shown in a way that
could connect the respondents or their companies with the results (Recker, 2013).

Also, the guidelines for an ethical study given by Bhattacherjee (2012) were followed, where
participation in the interviews, as well as the surveys was voluntary, and before starting the
interviews, we informed the participants about our intent, and asked them for their permission to
have the conversation recorded, we also were conscious about not to ask any personal irrelevant
questions. Further, we ensured to the interviewees that their data would be treated in a confidential
way (Recker, 2013).

Moreover, the ethical guidelines given by Bhattacherjee (2012) were also considered during
data analysis and results sections, making sure that no findings were left out, and clearly describing
each step taken during the research.

24
3. Results
In this chater the results of our study will be presented. It starts with the survey, where we present
the tests performed to interpret our data and hypotheses. Followed by analysis of the interviews,
where we present the main findings related to our study.

4.1 Analysis of surveys

4.1.1 Survey’s reliability analysis

In order to test the reliability of questionnaire’s items, the Internal Consistency Reliability (ICR)
and factors loading are used. This has been done using the reliability coefficient Cronbach’s alpha.
The Cronbach’s alpha is commonly used by quantitative researchers, as a measurement of internal
consistency reliability (Yi & Hwang, 2003; Lee et al., 2011).

The value of Cronbach’s alpha coefficient depends on the correlations between a group of
items of a specific factor. Thus, any increase of correlations results in an increase of the Cronbach’s
alpha coefficient value. However, the result of Cronbach’s alpha reliability test in our case is equal
to 0.844. This indicates a strong and reliable level of the ICR and the data, as the values of
Cronbach’s alpha coefficient greater than 0.7 are considered to be reliable (Wixom & Todd, 2007;
Park, 2009).

4.1.2 Implementation of risk monument among respondents

To know the distrubation of companies applying risk management among our respondents, the
following question has been asked “Does your current company has any risk management process”
the figure below presents the respondents’ answers 60.3% of them said yes, and 39.7% said no.

39,70%

60,30%

Yes No

Figure 3.1 Distribution of companies implementing RM in our dataset

25
4.1.3 Risk management to prevent projects failure

In order to know whether risk management prevents projects failure, the following question has
been asked “In your opinion, does software risk management prevents software project failure?”.
69% of the respondents agreed that software risk management prevents software failure, while the
other 31% disagreed.

31%

69%

Yes No

Figure 3.2 Respondents’ opinions on risk management to prevent project failure

4.1.4 Descriptive statistics & interpretation of hypotheses

In this section we will present the descriptive statistics results of the seven hypotheses we have in
our survey. Each one of them and its corresponding response will be briefly discussed.

Meeting User Requirements (MUR)

Table 4.1 and Figure 4.3 show the percentages of responses on the first hypothesis "software risk
management ensures meeting user requirements" (Skewness= -.609, Mean=3.50, Median= 4.00,
Mode= 4.00, STD= 1.183) this indicates that most of the distribution is at right (agree and strongly
agree). In total, 56.9% of the respondents agreed, 24.1% were neutral, and 18.9% of the
respondents disagreed.

26
 Figure 3.3 Respondents’ opinions on RM to ensure meeting user requirements

Completing the Project (CTP)

Table 4.1 and Figure 4.4 demonstrate the results for the second hypothesis “software risk
management ensures completing the project (i.e., the project was not canceled)” is moderately
skewed left, negatively skewed (Skewness= -.582, Mean= 3.46, median= 4.00, Mode= 4.00, STD=
1.167) this indicates that the majority of the participants agreed that software risk management
ensures completing the project. In total 60.3% of the respondents agreed, 15.5% were neutral, and
only 24.1% of them disagreed.

Figure 3.4 Respondents’ opinions on RM to ensure completing the project

27
Completing the project within budget (CPB)

Table 4.1 and Figure 4.5 shows respondents' opinion on whether risk management ensures
completing the project within budget or not (Skewness= -.575, Mean= 3.51, Median= 4.00, Mode=
4.00, STD= 1.168) which means that most of them confirmed that risk management ensures
completing the project within budget. In total, 58.6% of the respondents agreed, 20.7 were neutral,
and 20.7% of them disagreed.

Figure 3.5 Respondents’ opinions on RM to ensure completing the project on budget

Completing the project on time (CPO)

Table 4.1 and Figure 4.6 demonstrate whether software risk management ensures completing the
project on time or not, the result shows that are negatively skewed, skewed left (Skewness= -.696,
Mean= 3.58, Median= 4.00, Mode= 4.00, STD= 1.103). Thus, this indicates that the majority of
the participants agreed on that. In total, 63.8% of the respondents agreed, 17.2% were neutral, and
19% of them disagreed.

28
 Figure 3.6 Respondents’ opinions on RM to ensure completing on time

High-quality software (HQ)

Table 4.1 and Figure 4.7 demonstrate whether software risk management ensures high-quality
software (having a solid and well-tested system) or not (Skewness= -.500, Mean= 3.37, Median=
3.50, Mode= 4.00, STD= 1.131). Thus, this indicates that most of the distribution is at the right. In
total, 50% of the respondents agreed, 31% were neutral, and 18.9% disagreed.

Figure 3.7 Respondents’ opinions on RM to ensure having a high quality software

29
Final systems works as intended (FSI)

Table 4.1 and Figure 4.8 demonstrate whether software risk management ensures that the final
system work as it should be or not (Skewness= -.637, Mean= 3.50, Median= 4.00, Mode= 4.00,
STD= 1.122) which indicates that most of respondents agreed on that. In total, 58.6% of the
respondents agreed, 22.4% were neutral, and 19% disagreed.

Figure 3.8 Respondents’ opinions on RM to ensure that final system works as intended

Customer satisfaction (CS)

Table 4.1 and Figure 4.9 illustrate whether software risk management ensures customer
satisfaction or not (Skewness= -1.160, Mean= 3.67, Median= 4.00, Mode= 4.00, STD= 1.028)
which reflects that the majority of the respondents agreed. In total, 70.7% of the respondents
agreed, 17.2% were neutral, and 12.1% disagreed.

Figure 3.9 Respondents’ opinions on RM to ensure customer satisfaction

30
Table 4.1 summarizes the means, medians, modes, standard deviation and the skewness for all the
hypotheses (MUR, CTP, CPB, CPO, HQ, FSI, and CS). The means for all of them were between
3.37 and 3.67 and this range of mean values depending on a scale of 1 to 5 (1=strongly disagree,
5=strongly agree) (See Appendix B).

HYPOTHESIS MEAN MEDIAN MODE STD SKEWNESS

MUR 3.50 4.00 4.00 1.183 -.609
CTP 3.46 4.00 4.00 1.167 -.582
CPB 3.51 4.00 4.00 1.168 -.575
CPO 3.58 4.00 4.00 1.103 -.696
HQ 3.37 3.50 4.00 1.131 -.500
FSI 3.50 4.00 4.00 1.122 -.637
CS 3.67 4.00 4.00 1.028 -1.160
Table 3.1 A summary of the statistical analysis performed on the tested hypotheses

We finalize this section with adding the answers of the last two open questions. The first one asked
the respondents to give examples of projects that do not require risk management. We got
responses from 24 respondents since the other 92 respondents think that all projects require risk
management process. The following are the examples that were given in the surveys:

- Small projects.
- In-house products.
- Mobile applications.
- Less security-oriented system
- Projects with no constrains (time and budget constrains).
Moving to the next open question, the respondents were asked to write list risks that might lead to
project failure. This question was not mandatory; therefore, we got responses from 58 respondents
only. The following is a list of risks that might be a reason of project failure:

- Poor planning.
- Seniors leave the work in project
- Lack of communication between the developing team and the customer.
- Difficulties that prevent working.
- Legislation risks.
- Changing or increasing the requirements.
- Lack of understanding the requirements.
- Bad cost, time, and resources estimation.
- Giving less priority for testing.
- The project's goals are not clearly formulated.
- Project manager might be afraid of making a decision.
-

31
4.1.5 Correlation analysis

In order to test the relationships between the purposed hypotheses that risk management is said to
be ensuring, and to see whether they influence each other or not, as well as to find out whether
they lead to customer satisfaction, as the customer is an important stakeholder and the product
owner, Pearson correlation was employed. Pearson coefficient (r) is a measure of the direction and
strength of a relationship that exists between at least two variables. However, the values of r have
an interval between [-1:1] where 1 indicates a strong positive correlation, -1 indicates a strong
negative correlation, and 0 indicates no correlation. Pearson correlation can be calculated using
the following formula:
√𝑐𝑜𝑣(𝑥,𝑦)
𝑟𝑥𝑦=
√𝑣𝑎𝑟 (𝑥)∗√𝑣𝑎𝑟(𝑦)

Where:
- cov(x,y): is the covariance between x and y.
- var(x) is the variance of x
- var(y) is the variance of (y).
The following are the results of testing the correlation of the proposed hypotheses and customer
satisfaction (See Appendix C for full correlation table).

Meeting user requirements and customer satisfaction.

After applying Pearson's correlation coefficient on the variable mentioned above (Meeting user
requirements and customer satisfaction) we got the following result: (r = 0.693**, n= 116, p=.000).
By looking at the r value, we realize that there is a significant strong positive correlation between
those variable. Thus, we can say that customer satisfaction is positively affected by meeting user
requirements.

Completing the project and customer satisfaction.

By applying Pearson’s correlation coefficient on the variables above we got the following result
(r = 0.302**, n=116, p= 0.001) by looking at the r value, we realize that there is a significant
correlation between those variable. Thus, we can say that there is a positive relationship between
completing the project and customer satisfaction.

Completing the project on budget and customer satisfaction.

Applying Pearson’s correlation coefficient on the variables above gave the following result:
(r = 0.403**, n=116, p= 0.000) which indicates a significant positive correlation. Thus, we can
say that there is a positive relationship between completing the project on budget and customer
satisfaction.

32
Completing the project on time and customer satisfaction.

The result of applying Pearson’s correlation coefficient on the variables above is the following
(r = 0.492**, n=116, p= 0.000) that shows a significant positive correlation between those two
variables. Thus, we can say that completing the project on time affects positively the customer
satisfaction.

High-quality software and customer satisfaction.

The result of applying Pearson’s correlation coefficient on having high-quality software and
customer satisfaction is the following (r = 0.586**, n= 116, p=.000) looking at the r value, we can
say that there is a significant positive correlation between those two factor, and that customer
satisfaction is positively affected by having a high quality strong.

Final system works as intended and customer satisfaction.

The result shows that having a system works as intended positively affects customer satisfaction.
As the result of applying Pearson’s correlation coefficient above shows the following values (r =
0.670**, n= 116, p=.000). Thus, the results show that there is a significant strong positive
relationship between the variables above.

4.2 Analysis of Interviews

Before beginning to present the results of the interviews, we will briefly summarize the
characteristic of our interviewees, mentioned earlier in table 3.4. Interviewee 1 was contacted
through LinkedIn. While we came in touch with interviewees 2, 3, and 4, through our own network
of friends. All of them working as software projects managers, except interviewee 2 who is a CTO.
We will refer to interviewee 1 (or I1 in interview quotes), interviewee 2 (I2), interviewee 3 (I3),
and interviewee 4 (I4).

It was very crucial for our study to understand how software risk management influence
software project success, how is that done in practice, and to see whether risk management has a
negative impact on project success, from those who perform the risk management process, i.e.
from a managerial perspective. The following describes their opinions and reveals some interesting
points that covers the gaps found in former studies.

4.2.1 Risks in software development

During the interviews, we asked the interviewees to give examples from their experience of risks
that might occur during the software development process. Interviewees mentioned the continues
changing requirements as a main source of issues (1, 2 & 4), project dependencies (Interviewee
1), bad communication (interviewee 2), and the bad assessment of the project (interviewee 3).

Three of the interviewees (1, 2 & 4) confirmed that the continues changing of requirements is
where the problems start to come up (interviewee 2). (Interviewee 1 & 4) agreed that changing of
requirements will lead to problems when it comes to integration testing, lead to delays, exceeding

33
the budget, and affect the quality. Interviewee 4 explained: “I think the most dangerous one is the
changing of requirements. Because this one lead to exceed the time and the budget, it also could
affect the quality, since you keep trying to meet the requirements, and it end up with a system that
has bugs” (Table F.1, row 6).

Project dependencies is according to (interviewee 1) is one of the problems that occur, when
you are waiting for another project to finish. He gave an example of working on a project for the
government, and they are working on another project that you are supposed to come and enhance
or add something to. He continued saying “usually governmental projects take a lot of time, this
is a big risk here.” (Table F.1, row 5).

The second interviewee (interviewee 2) mentioned several risk factors like people getting sick,
people going for a vacation, misunderstanding and bad communication. He emphasized on the
communication especially when you ask the team, how is it going and said: “That people report
how is it going. So if you ask how is it going not just always sound going good. If people always
tell you this, then it is bad it is a trick it is not going good” (Table F.1, row 2).

One of the interviewee (interviewee 3) named bad assessment where the manager fail to
estimate the amount of work needed as a risk. He illustrated saying “[…] I have seen small projects
for on first look you would think that would take top 20, 30 hours to finish, but it escalates really
quick […]” (Table E.3, row 29).

4.2.2 Success criteria’s in software development

Since that our study is all about the influence of software risk management on software project
success, it is important for us to understand what does success in software development project
actually mean. Therefore we asked our interviewees to identify success, and what makes a project
to be considered as a successful project. We got the following answers.

Meeting user requirements, on time, on budget are the basic success criteria’s (Interviewee 2
& 4), happy customer (interviewee 3 & 4), happy and proud team (interviewee 3 & 4).

However, the first interviewee (interviewee 1) had a slightly different definition: “A successful
project is a project that meets the user requirements, and it does not exceed its budget and time
with more than 25%. However, this is not always the case.” (Table F.1, row 15). Then he was
asked to elaborate, so he added: “I mean sometimes it is acceptable to exceed the budget even with
more than 25%, if I meet other strategic goals.” (Table F.1, row 15). He was asked again to clarify
what he meant by strategic goal, so he answered saying: “strategic goal which is getting a new
customer, which will bring to us more projects.” (Table F.1, row 15).

4.2.3 The relationship between risk management and project success

Since that our study is all about investigating the relationship between software risk management
and software project success, it was crucial for us to understand in depth how is software project
success is influenced by software risk management, and to do that we asked our interviewees to
describe how does risk management ensures meeting the success criteria’s they mentioned, as well
as the success criteria’s found in the literature. The following illustrates the answers received from
the interviewees.

34
 Risk management ensures things in place (interviewee 2, 3 & 4), risk management assures, a
better communication with the customer (interviewee 2 & 4), an involvement of the staff
(interviewee 3), identifying risks and avoiding them (interviewee 1 & 4), and giving chances for
the company (interviewee 1).

Further, the interviewees were also asked to give their impression on the relation between
software risk management and success criteria’s identified in the literature, to see whether risk
management contribute to those criteria or not. There was a total agreement among all of the
interviewees on the following criteria’s: meeting user requirements, completing the project on
time, completing the project on budget, completing the project (project was not cancelled), and
that final system works as intended (interviewee 1, 2, 3 & 4). Three of the interviewees
(interviewee 1, 3 & 4) agreed that risk management ensures having a satisfied customer, while
(interviewee 2) showed a neutral impression. Finally, three of the interviewees (1, 2 & 4) answered
with “neutral” when we asked them whether risk management ensures a high quality system, while
(interviewee 3) strongly agreed on that.

For interviewees (2, 3 & 4) risk management appears helps in ensuring success of the project,
as it ensures having things in place. Interviewee 2 said for example: “[…] to ensure that things
are in place before you start a project […]” (Table E.2, row 27). Interviewee 3 added on that
saying: “it is easy to steer away from the goal […] those meeting and the risk assessment you have
helps to prioritize what is most important for me to finish this week” (Table E.3, row 17).

Interviewees (2 & 4) mentioned that risk management helps in having a better communication
with the customer. Interviewee 2 mentioned even that letting the customer know what kind of risks
are we facing might make the customer forgive some mistakes and problems at the end of the
project.

Interviewee 3 pointed that risk management, particularly the risk assessment part ensures
having a happy staff. In this context he said the following: “These assessments are really important
so that the staff to keep them happy they have to say the word, what they think about and how they
think about the project so that you can communicates this to the customer” (Table E.3, row 23).

Interviewees (1 & 4) mentioned that risks management helps in identifying risks and avoiding
them. Interviewee 1 sees that risk identification helps the company achieving some strategic goals.
He illustrated saying: “you identify the risks, and you realize that this project is going to take extra
time, but as I said before you will work on that extra time, and make a strategic goals, like as I
said, build a good relation with the customer, and getting us more projects.” (Table E.1, row 18).

Further, it was really interesting to hear different opinions from the interviewees about project
success criteria identified in the literature. Apart from the criteria that the interviewees agreed on,
interviewee 2 stated a neutral opinion when asked whether risk management ensures customer
satisfaction. He explained the underlying reason saying: “sometimes customer satisfaction
depends on other things. And you may not be able to tackle with risk management alone.” (Table
E.2, row 60). Moreover, interviewees (1, 2 & 4) stated a neutral opinion on (risk management
ensures having a high quality system), interviewee illustrated that as he said: “The quality part is
not always achieved, if the customer has changed the requirements multiple times, […] you will
have problems when it comes to integration testing […] sometimes you will deliver the product to

35
the customer even that you know it’s not well tested” (Table E.1, row 42). However, interviewee
3 has strongly agreed, the interviewee explained: “this where risk management shines this is where
you can really put all your ideas to test before you try to implement them, risk management ensures
that.” (Table E.3, row 54).

Moreover, the interviewees were asked to clarify whether risk management prevents failure.
Two of the interviewees (1 & 3) agreed on that. Interviewee 1 explained: “Of course it does, all
projects need a risk management. Risk management is all about identifying risks, analyzing, and measuring
their severity. Depending on their severity you will make a plan, and a backup plan, that in case they occur,
you know what to do” (Table E.1, row 22). However, interviewee (2 & 4) disagreed on that, interviewee 2
said in this context: “Just by itself. I think it cannot prevent failure or guarantee to prevent failure. But I
think it is an important tool in every project to assure or reduce the probability is that something fails, to
increase the probability that it is a success” (Table E.2, row 33).

4.2.4 Negative impact of risk management on project success

One of the gaps found in literature concerns that risk management is a risky process, and that it
has a negative impact on project success. Thus, in order to fill the gaps, interviewees were asked
to elaborate more on this point.

Interviewees (1, 2 & 3) agreed that overdoing risk management might leave a negative on
project success. Interviewees (2 & 4) confirmed the badly performed risk management, might lead
to unwanted results. Interviewee 2 has even mentioned that risk management is a tricky process.

Overdoing risk management, consumes time and increases the budget (interviewee 3).
Interviewee 1 mentioned that risk management in this case makes you get busy with less important
things instead of focusing on the main goal, as an example he said: “There is a risk that the
electrical power might cut for a whole year, but what is the chances for that risk to occur? Almost
zero. But if you keep talking and analyzing about that risk and thinking that I must have a backup
generator before starting the project, then you are getting busy with it […]” (Table F.1, row 13).

For interviewee (2 & 4) badly performed risk management, has a negative impact on project
success. In such a situation you may draw the wrong conclusions, which in turns would make the
customer panic, and then he asks to cancel the project (interviewee 2). Interviewee 4 gave an
example of a badly performed risk management: “when you do not involve the customer in your
risk management process, so that the customer does not get to say his word about the risks he
thinks that might exists, so you start working while you have risks hidden on customer’s side”
(Table F.1, row 12).

Interviewee 2 mentioned that risk management is a tricky process, as it might make you feel
safe for a while, but then this could lead to a chaos. He elaborated on that saying: “the trick risk
management is makes you feel good for one or two or three sprints, then you are a little bit relaxed.
You don't follow your routine and suddenly you come back from vacation and its chaos” (Table
F.1, row 4).

36
4. Discussion
In this chapter, we will answer our research question. We will do this based on the literature review
and the outcomes of the conducted of the survey and the interviews. Finally, we will draw a general
conclusion that forms an answer to our main research question.

5.1 What are the risks in software development?

Software development is a risky process, which makes it obedient to a large amount of risks. The
literature has already identified different lists containing tens of risks that might appear during the
software development process. Yet, and as risks in software development are dynamic, i.e. they
keep changing and appearing depending on the nature of the project. It is hard to know to what list
should project managers and companies refer to. In this context, the literature encourages
development companies to develop their own list of risks based on their experiences.

However, the following table summarizes the risks found through the conducted survey and
interviews.

Risks found throug survey’s Risks found throug interviews

 Seniors leave the work in project  Continues changing of requirements
 Lack of communication between the  Project dependencies
developing team and the customer.  Bad communication
 Difficulties that prevent working.  Bad assessment of the project
 Legislation risks.
 Poor planning.
 Changing or increasing the
requirements.
 Lack of understanding the
requirements.
 Bad cost, time, and resources
estimation.
 Giving less priority for testing.
 The project's goals are not clearly
formulated.
 Project manager might be afraid of
making a decision.
Table 4.1 Risks found through conducted survey and interviews

37
5.2 What are the success criteria’s in software development?
It was crucial for our study to understand what success in software projects means. It was also
mentioned in the literature that in order to understand the influence of software risk management
on project success, success must be viewed from a wider perspective, rather than viewing it
considering meeting the classical triangle of success: time, budget, and requirements. The
following table summarizes different success criteria, found based on the conducted literature
review, and on the gained results.

Success criteria based on literature review Success criteria based on our findings
 Meeting user requirements  Meeting user requirements
 Completing the project (project was  Completing the project on time
not cancelled)  Completing the project on budget
 Completing the project on time  Happy customer
 Completing the project on budget  Happy team
 High quality software (solid and well-  Meeting strategic goals
tested system)
 Final system works as intended
 Customer satisfaction
Table 4.2 Success criteria based on the literature review and the gained results

5.3 What is the relation between risk management and project

success?
As mentioned earlier, studies show that the failure rate in software development projects has
reached 71%, which is considered to be high. Failure in software projects occurs due to different
risks. Needless to say, the ethereal nature of software, makes software development a risky
process. However, the literature suggests implementing some kind of a risk management process,
in order to minimize the high failure rate in software development.
Nevertheless, it has also been reported in the literature that risk management by itself is a risky
process. Some research have even stated that risk management has a negative impact on project
success. Thus, in order to understand the relation between risk management and project success,
and to know how risk management contributes to project success in practice. We surveyed 116
field workers and conducted interviewees with project managers and a CTO, to get a satisfying
answer to this problem.
The results show that the 69% of the survey respondents agree on that risk management prevent
software failure. Added to them two of the interviewees who strongly agreed on that point.
However, the other 31% who disagreed, were supported by the other two if the interviewees. One
of the interviewees elaborated on this point, saying that risk management cannot prevent project
failure by itself, but it is a tool that decreases the probability of failing and increases the probability
of succeeding.
Furthermore, the results of the survey, show diverse distributions of respondents who agreed
on the proposed hypotheses (success criteria ensured by risk management), where the minimum
percentage of the agreed answers was 50% on high quality, and the maximum was 70% on meeting

38
user requirements. This was also the case with the interviewees, as one could see different opinions
on some point, namely high quality and customer satisfaction.

5.4 General discussion

Coming back to our main research question “what is the influence of software risk management
on software project success?”, generally, as well as in practice and based on our findings, we are
able to say that software risk management has a positive influence on software project success as
it ensures meeting several project success criteria. Yet, this influence has a certain extent, i.e. risk
management does defiantly help in identifying the risks that may occur during the software
development process. Yet, planning on how to deal and mitigate those risks is up to the project
manager or the company itself.
Furthermore, this extent might become a risk that leads to an increase of time and budget, affect
the quality, or even leads to failure. That could occur in cases where risk management has been
misused so it leads to wrong conclusions, or where risk management has been overly done, so
workers get busy with the wrong stuff, instead of focusing on the main goal. One of the
interviewees has even mentioned that risk management could be tricky, as it makes the staff feel
safe and sure of what is going on of one or two or three sprints, so they start skipping their routines,
but suddenly things turn into a total chaos.
Nevertheless, this study has found a relation between risk management and ensuring customer
satisfaction. Through finding the correlation between several success factors that risk management
ensures meeting, with customer satisfaction.
To conclude, and based on survey’s and interview’s results, we can say that implementing a
software risk management process, neither grants success nor prevents failure. Risk management
is a tool that is if used well it increases the probability of success. On the other hand, it could
increase the probability of failure if misused, this has also been supported by our interviewees.

39
5. Conclusion
We conduct a study to find whether software project success is influenced by software risk
management, and to see if risk management contributes to project success, and if so, then how is
that achieved in practice.
We survey field workers, where we test seven hypotheses to get an answer for the problem.
We plot graphs to see the distribution of participants’ opinions on the tested hypotheses. We
calculate correlations between different hypotheses and customer satisfaction.
Further, we interview project managers for a deeper understanding of the problem. We ask
them to elaborate on crucial points of our study. We use the results from both the survey and the
interviews to answer our research questions.
However, this study is conducted on small and med-sized companies, up to 250 workers. Thus
we do not know if the answers are valid for bigger companies.

6.1 Contribution of the study

As a result of the research findings, this study addressed an important contribution to the literature
by investigating the effects of risk management on project success in practice. This has been done
by taking a wider perspective of “success criteria” in software projects, rather than just focusing
on the typical triangle of success: on time, on budget, and meeting requirements, and to the best
of our knowledge, this is the first study who does that
Further, based on the results, we recommend companies and project managers, to perform a
risk management process on each project they get to work on, despite its size or complexity.
However, in such a case it does not need to be formal process, rather than just having a thought
about the risks that might occur.
Nevertheless, in this context we would like to repeat and say that implementing a software risk
management process, does not grant success. Risk management is a tool that is if used well it
increases the probability of success. On the other hand, it could increase the probability of failure
if misused.

6.2 Future research

We acknowledge some limitations to our study that need to be highlighted to recommend the need
for future research. In this research we have limited our study to small and med-sized software
development companies, i.e. companies that have software development as the main business, and
have up to 250 workers. Future research may focus on bigger companies, and/or companies having
software development as a part of their business, to see whether the results differ or not. Also in
our research, we surveyed practitioners, namely developers, testers, and project managers/leaders.
Future research may consider focusing only on project managers and risk analysts.

40
Appendix A – Survey questionnaire
As a part of our Master’s thesis, at Lund University, we are conducting a survey that investigates the
impact of software risk management on project success. We will appreciate if you could answer the
following questions. Any information obtained in connection with this study will remain confidential.
 Company Name (Optional): _____________
 Nr. Of workers at the company:
o 1-49 workers.
o 50-99 workers.
o 100-149 workers.
o 150-199 workers.
o 200-250 workers.

 Country working in: ______________

 Position:
o Project Manager / Leader.
o Developer.
o Tester.
o Other __________

 Years of experience:
o 0 - 3 Years.
o 4 – 7 Years.
o More than 7 Years.

 Level of Education:
o High school.
o Bachelor.
o Masters.
o PhD.
o Other _______

 Does your current company have any kind of risk management process?
o Yes o No

 In your opinion, does software risk management prevent software failure?

o Yes o No

41
 Software risk management ensures:

1= Strongly Disagree 2= Disgree 3= Neutral/ I don’t know 4= Agree 5= Strongly Agree

Meeting user requirements:

1 2 3 4 5
o o o o o
Completing the project (i.e. project was not cancelled):
1 2 3 4 5
o o o o o
Completing the project within budget:
1 2 3 4 5
o o o o o
Completing the project on time:
1 2 3 4 5
o o o o o
High quality software (Having a solid and well-tested system):
1 2 3 4 5
o o o o o
Final system works as intended:
1 2 3 4 5
o o o o o
Customer satisfaction:
1 2 3 4 5
o o o o o

In your opinion, do all projects require a risk management process?

o Yes o No

If no, please give examples of software projects that does not require a risk management process?
______________________________________________________________________________

In your opinion, what are the risks that might lead to project failure?
______________________________________________________________________________

42
Appendix B – descriptive statistics of surveys.

Meeting user requirements (MUR)

Frequency Percent Valid Percent Cumulative
Percent
Valid Strongly 10 8.6 8.6 8.6
Disagree
Disagree 12 10.3 10.3 19.0
Neutral 28 24.1 24.1 43.1
Agree 42 36.2 36.2 79.3
Strongly 24 20.7 20.7 100.0
Agree
Mean Median Mode Std.Deviation Skewness
Meeting user 3.50 4.00 4.00 1.183 -.609
requirement

Completing the Project (CTP)

Frequency Percent Valid Percent Cumulative
Percent
Valid Strongly 8 6.9 6.9 6.9
Disagree
Disagree 20 17.2 17.2 24.1
Neutral 18 15.5 15.5 39.7
Agree 50 43.1 43.1 82.8
Strongly 20 17.2 17.2 100.0
Agree
Mean Median Mode Std.Deviation Skewness
Completing 3.46 4.00 4.00 1.167 -.582
the Project

Completing the Project on Budget (CPB)

Frequency Percent Valid Percent Cumulative
Percent
Valid Strongly 8 6.9 6.9 6.9
Disagree
Disagree 16 13.8 13.8 20.7
Neutral 24 20.7 20.7 41.4
Agree 44 37.9 37.9 79.3
Strongly 24 20.7 20.7 100.0
Agree
Mean Median Mode Std.Deviation Skewness

43
Completing 3.51 4.00 4.00 1.168 -.575
the Project on
Budget
Frequency Percent Valid Percent Cumulative
Percent
Valid Strongly 6 5.2 5.2 5.2
Disagree
Disagree 16 13.8 13.8 19.0
Neutral 20 17.2 17.2 36.2
Agree 52 44.8 44.8 81.0
Strongly 22 19.0 19.0 100.0
Agree
Mean Median Mode Std.Deviation Skewness
Completing 3.58 4.00 4.00 1.103 -.696
the Project on
Time

High Quality Software (HQ)

Frequency Percent Valid Percent Cumulative
Percent
Valid Strongly 10 8.6 8.6 8.6
Disagree
Disagree 12 10.3 10.3 19.0
Neutral 36 31.0 31.0 50.0
Agree 40 34.5 34.5 84.5
Strongly 18 15.5 15.5 100.0
Agree
Mean Median Mode Std.Deviation Skewness
High Quality 3.37 3.50 4.00 1.131 -.500
Software

Final System Works as Intended (FSI)

Frequency Percent Valid Percent Cumulative
Percent
Valid Strongly 8 6.9 6.9 6.9
Disagree
Disagree 14 12.1 12.1 19.0
Neutral 26 22.4 22.4 41.4
Agree 48 41.4 41.4 82.8
Strongly 20 17.2 17.2 100.0
Agree
Mean Median Mode Std.Deviation Skewness

44
Final System 3.50 4.00 4.00 1.122 -.637
Works as
Intended

Customer Satisfaction (CS)

Frequency Percent Valid Percent Cumulative
Percent
Valid Strongly 8 6.9 6.9 6.9
Disagree
Disagree 6 5.2 5.2 12.1
Neutral 20 17.2 17.2 29.3
Agree 64 55.2 55.2 84.5
Strongly 18 15.5 15.5 100.0
Agree
Mean Median Mode Std.Deviation Skewness
Customer 3.67 4.00 4.00 1.028 -1.160
Satisfaction

45
Appendix C – Pearson Correlation

Correlations
mur cs ctp cpb cpo hq fsi
** ** ** ** **
mur Pearson Correlation 1 ,693 ,321 ,352 ,280 ,532 ,569**
Sig. (2-tailed) ,000 ,000 ,000 ,002 ,000 ,000
N 116 116 116 116 116 116 116
** ** ** ** **
cs Pearson Correlation ,693 1 ,302 ,403 ,492 ,586 ,670**
Sig. (2-tailed) ,000 ,001 ,000 ,000 ,000 ,000
N 116 116 116 116 116 116 116
ctp Pearson Correlation ,321** ,302** 1 ,638** ,542** ,168 ,444**
Sig. (2-tailed) ,000 ,001 ,000 ,000 ,072 ,000
N 116 116 116 116 116 116 116
** ** ** **
cpb Pearson Correlation ,352 ,403 ,638 1 ,761 ,153 ,265**
Sig. (2-tailed) ,000 ,000 ,000 ,000 ,101 ,004
N 116 116 116 116 116 116 116
** ** ** **
cpo Pearson Correlation ,280 ,492 ,542 ,761 1 ,141 ,295**
Sig. (2-tailed) ,002 ,000 ,000 ,000 ,132 ,001
N 116 116 116 116 116 116 116
** **
hq Pearson Correlation ,532 ,586 ,168 ,153 ,141 1 ,602**
Sig. (2-tailed) ,000 ,000 ,072 ,101 ,132 ,000
N 116 116 116 116 116 116 116
fsi Pearson Correlation ,569** ,670** ,444** ,265** ,295** ,602** 1
Sig. (2-tailed) ,000 ,000 ,000 ,004 ,001 ,000
N 116 116 116 116 116 116 116
**. Correlation is significant at the 0.01 level (2-tailed).

46
Appendix D – Interview questions
The influence of software risk management on software project success

A structured and semi-structured interview

City name: ________
Name of the interviewer: _________
Place and Date: _________
Type of interview (Phone, Skype call, in person): ________

(These data serve only for possible further contact, for example in case something is not clear in the
recording. These data will not be made public).
Name affiliation and organization role of the interviewee: ________________
years of experience: _______________
At what time did the interview start? _____
 [Open question] How do you define a successful project? I.e. what are the key characteristics of
a successful project?
_____________________________________________________________________________
_____________________________________________________________________________

 [Open question] From your definition to project success, do you think that risk management
contribute to project success? How?
_____________________________________________________________________________
_____________________________________________________________________________

 [Open question] How do you define software development risk? Please give examples of
software development risks that could lead to project failure.
_____________________________________________________________________________
_____________________________________________________________________________

 [Open question] In your opinion, does software risk management prevent software failure? If
yes, then how?
_____________________________________________________________________________
_____________________________________________________________________________

 [Open question] some research shows that software risk management has negative impact on
project success, is that possible? In which situations?
_____________________________________________________________________________
_____________________________________________________________________________

 The following criteria’s were identified in the literature as project success criteria’s. On a scale
between 1 to 5 where one is strongly disagree and 5 is strongly agree, does risk management

47
 ensure meeting those criteria’s?

Strongly Disagree Nature Agree Strongly

Disagree Agree

meeting user
requirements
completing
the project
(the project
wasn’t
cancelled)
completing
the project on
budget
completing
the project on
time
high quality
software
(having solid
and well
tested system)
final system
works as
intended
customer
satisfaction

 [Open question] Please describe how does risk management contribute to the project success
criteria’s you agreed on?
______________________________________________________________________________
______________________________________________________________________________

 In your opinion, do all projects require a risk management process?

o Yes o No

 If no, please give examples of software projects that do NOT require a risk management process.
______________________________________________________________________________
______________________________________________________________________________

48
Appendix E – Interview Transcripts

First Interview
Type of interview: Phone Call
City: Lund Sweden – Riyadh Saudi Arabia

Interviewer: Hiba Arafeh

Interviewee: I1 (for the anonymity of the interviewees, names and working place are removed)
Table E.1: Transcription of interview 1
1 Hiba First, we would like to thank you for giving us this chance, we really appreciate
that. We also we would like to inform you that any personal information obtained
will remain confidential, and will serve only for possible further contact. Is that ok?
2 I1 Yeah, it is ok.
3 Hiba What is your name?
4 I1 ...
5 Hiba Which company you working at?
6 I1 It is …
7 Hiba And number of workers at the company
8 I1 We have two offices, both in Riyadh Saudi Arabia and Cairo Egypt, with a total of
150 workers.
9 Hiba And your level of education and years of experience?
10 I1 I have a bachelor degree, and have been working for 15 years in software
development field, out of them 8 years as a project manager.
11 Hiba How do you define a successful project? I mean what are the characteristics of a
successful project?
12 I1 A successful project is a project that meets the user requirements, and it does not
exceed its budget and time with more than 25%.
However, this is not always the case.
13 Hiba What do you mean by it is not always the case? Can you explain more?
14 I1 Mmm, I mean sometimes it is acceptable to exceed the budget even with more than
25%, if I meet other strategic goals.
15 Hiba Strategic goals?
16 I1 Yes, like getting a new customer. We are a software development company, no
hardware working, the budget for us means developers payments, so sometimes
you will ask your developers to work extra to meet the schedule, and then you will
have to pay them more. But in this case, you made a strategic goal, which is getting
a new customer, which will bring to us more projects.
17 Hiba From your definition to project success, do you think that risk management
contribute to project success? How?
18 I1 Yes, since you identify the risks, and you realize that this project is going to take
extra time, but as I said before you will work on that extra time, and make a

49
 strategic goals, like as I said, build a good relation with the customer, and getting
us more projects.
19 Hiba How do you define software development risk? Please give examples of software
development risks that could lead to project failure.
20 I1 A risk is something that might occur, and hinder you from achieving your goals.
The main problem is change of requirements, in the Middle East area, from my
experience, I can say that the customer does not really know what he want. so we
start a project as we think that the customer want, but after a while and after
delivering a part of the system to the customer, he realize that this is not how he
was thinking, and here the problems start to come up. Also, in the Middle East
area, one of the problems occur, when you are waiting for another project to finish,
let’s say that you are working with the government, and they are working on
another project that you are supposed to come and enhance or add something on or
whatever, usually governmental projects take a lot of time, this is a big risk here.
21 Hiba In your opinion, does software risk management prevent software failure? If yes,
then how?
22 I1 Of course it does, all projects need a risk management. Risk management is all
about identifying risks, analyzing, and measuring their severity. Depending on their
severity you will make a plan, and a backup plan, that in case they occur, you know
what to do. Instead of just working with no idea of what you are going to face.
23 Hiba Alright
24 I1 Yeah
25 Hiba Some research shows that software risk management has negative impact on
project success, is that possible? In which situations?
26 I1 Yes, that is possible.
27 Hiba How?
28 I1 As I said, risk management is all about identifying and analyzing risks. Risks are
everywhere, there is a risk that the electrical power might cut for a whole year. But
what is the chances for that risk to occur? Almost zero. But if you keep talking and
analyzing about that risk and thinking that I must have a backup generator before
starting the project, then you are getting busy with it instead of working on other
more important points.
29 Hiba So you are saying that over analyzing less important risks or over doing risk
management, can lead to troubles?
30 I1 Yes
31 Hiba Ok then, the following criteria’s were identified in the literature as project success
criteria’s. On a scale between 1 to 5 where one is strongly disagree and 5 is
strongly agree, does risk management ensure meeting those criteria’s?
32 Hiba Please describe how does risk management contribute to the project success
criteria’s you agreed on?
33 Hiba Meeting user requirements you gave 5

50
34 I1 As I said earlier, the customer would keep changing the requirements, so knowing
from the beginning that there is a chance for that to occur, you would have already
planned for that and know what to do in case that happens.
35 Hiba Completing the project: you gave 5 for that
36 I1 As I said since you already know what kind of risks you might face for the specific
project, so you are aware of how to handle them.
37 Hiba Completing the project on budget 5
38 I1 yes, again risk management, helps you knowing what kind of risks you will face,
and you know that this project might need more work, so you will plan not to
excessed the planned budget, but as I said ok to exceed the budget with up to 25%
or even more if it going to make me achieve one or more strategic goals.
39 Hiba Completing the project on time you gave 5
40 I1 I think that this point is related to the previous one, you know that this project
might take a longer time, as the customer has changed his requirements, so you
plan depending on that.
41 Hiba High quality software, here you gave 3
42 I1 Yes, the quality part is not always achieved, for example, if the customer has
already changed the requirements multiple times, but you still want to deliver the
product on time, to have a customer satisfaction, you will have problems when it
comes to integration testing and that can lead to delays. So sometimes you will
deliver the product to the customer even that you know it’s not well tested, and it
has bugs. But those bugs should be within an acceptable level. Sometimes even the
customer won’t realize that there are problems in the systems. But as a
programmer, and as a matter of ethics and morals, I should go to the customer and
fix those problems in the place.
43 Hiba Final system works as intended 5
44 I1 definitely, it helps you delivering the product with full functionality, even though it
could have some bugs, but you are still aware of this point because of the plans you
made on managing the risks.
45 Hiba Customer satisfaction you gave 4
46 I1 yes customer satisfaction is a relative word, you do your best to achieve that, but
the changing requirements sometimes, makes you want to deliver the system even
with less quality product as we talked about. Sometimes you will deliver the
system even with bugs as I said, to avoid any delays.
47 Hiba In your opinion, do all projects require a risk management process? Yes or No
48 Hiba And If no, please give examples of software projects that do NOT require a risk
management process.
49 I1 Yes all project definitely need a risk management plan.
50 Hiba All?
51 I1 Yes all, it might be zero risks, but I still have to make the plan and right that the
chances of this and this and that risks are almost zero, which basically means that I
have no risks, but I still need to make the plan.
52 Hiba Despite how big or small the project is?

51
 53 I1 There is no big or small projects, a project is a project, and the plan should be
made.
54 Hiba Would you like to add anything else?
55 I1 No am fine
56 Hiba so, we would like to say many thanks for you, for giving us your time.
57 I1 No problem, good luck
58 Hiba Bye
59 I1 Bye

Second Interview
Type of interview: In person
City: Växjö Sweden

Interviewer: Adham El-Ahmad

Interviewee: I2 (for the anonymity of the interviewees, names and working place are removed)
Table E.2: Transcription of interview 2
1 Adham OK. So first of all I'd like to thank you for giving us the chance to meet you and to
talk about our thesis which is all about the influence of software risk management
and software project success in the small and mid-sized companies.
2 I2 Yeah
3 Adham First of all we would like to know your name, your organization and your role,
this data will not be published and it will only for out on purpose.
4 I2 Yeah, good good.
5 I2 So my name is … and I'm CTO of … in Växjö we have an I.T. consulting
company with about 25 employees. It's close to 20 working in production means
development, testing and project management group and we have internal and
external projects working with.
6 Adham And your years of experience?
7 I2 My experience working years and years of experience and my experience is about
eight years since I finished my Ph.D. and then a question if you count these years
five years doing Ph.D.
8 Adham I see
9 Adham So if we move forward we would like to know. As you work as CTO how you do
define a successful project. In other words what are the key characteristic for a
project.
10 I2 Yes a successful project it is basically, that it is does what it is supposed to do is
meet the requirements.
11 Adham Ok?
12 I2 The second is that it is in budget.
13 Adham In budget

52
14 I2 And the third is its time and means delivered within the deadline we have
15 I2 And usually it is right if you have a project which doesn't do what it's supposed to
do and its complete failure, is just the wrong things. And of course there's a
different degrees. Sometimes it just misses a few features and this is not issue.
Usually is that we have a project which doesn't do what it's supposed to do, this
never happened really. You know usually it's not just some bugs if you fix it. This
is usually not that thing that's the main criteria that the project needs to do what
it's supposed to do. And the most important thing is that it's
Within budget and that's usually the most difficult thing to get done. If you start a
project and you have certain expectations and you don't know things, projects they
may under-finance from the beginning.
And just from experience of projects they fail because they should still get more
budget and the project gets finished and everything is good. But maybe you can
be considered as a failure because you exceeded the budget.
And we did not yet have to cancel the project because it wasn't on budget. Our
company didn't have this problem.
And then the last one is usually if you deliver it in time and they're usually the
most flexible customers usually what it takes is that it takes more time and more
time means more budget. My timings usually calendar time within the deadline.
16 Adham So I believe that time is also what you consider as payment for those developers?
17 I2 yeah its two things that one is a time the working hours we spend, And the other
one is when there's a certain schedule a deadline we need to finish the project,
And this is would be also could be also a failure if you exceed this deadline and
often you can shift these deadlines. So on many projects this is not a problem
18 Adham Without paying extra?
19 I2 This is usually that people, the customer have to pay extra, sometimes not
20 Adham It is like in a brief you said three main different things: different requirements in
budget and in time.
21 I2 Yes
22 Adham So we can go to Next question which is from your definition.
Where you are saying in budget and requirement and in time how does risk
management help you to achieve that goal. So let’s say requirements, how can
you meet requirements with risk management?
23 I2 yes and that the work are said You assure is that you have a product owner that
have good requirements analytics proses that you are defining your requirements
and you're following them up during the project, And to assure this You make
sure you have the right people in place for doing this. You may want to make sure
as the customers has the capability of delivering the requirements
24 Adham What do you mean?
25 I2 That if you ask the customer what do you want us to do. He can explain it and not
have a fuzzy idea which changes all the time. If you have this if you have a
moving target then it's also a problem. And then this could result in more work,
wasted work possibly exceeding budget or time limits.
26 Adham So you are saying that risk management helps you to plan for these problems.

53
27 I2 Yes it could allow you in the beginning to do this and to ensure that things are in
place before you start a project that you would have the assessment of the project.
What do we think? What budget do we need?
28 Adham Ok
29 I2 Do we know all the requirements or is it that which project model will use if it's a
really unclear thing then it's probably high agile that we just fall into small steps
forward.
One Sprint after another to see where we end up. If it is a plain vanilla
straightforward project to requirements on the table you can more or less just
assess how much does it cost to deliver a little bit waterfall style to say okay this
is what we develop and then that's usually the easiest part. It doesn't happen too
often and you have projects in consulting where everything is clear from the
beginning and then assuring that you keep budget time and the requirements of
the project plus a happy customer maybe in this case that you need to follow it up
constantly. Constantly during the project seeing are there any deviations?
informing the customer about this getting them signed that the customer is aware
of that and at the end there is no big surprise, so he say this is not what I ordered
and am not going to pay, for example.
So the risk management is where we try to assess it in the beginning where are we
can you follow up if anything really change. And then you are always on your
toes to make sure you identify potential issues and most of it comes from
requirements that it's not clear what should you do. And implementation wise is
not so often issues and they are usually straightforward if you know what to do
and you're not sure how to do it, and you figured out pretty fast but if you don't
know what to do or if the customer changes the idea. This may require quite a lot
of rework.
30 Adham OK. Well the question will be how you define software development risk. And
can you please give examples of risks that can lead you to failure?
31 I2 It is basically the possibility or the probability that events happen which result in a
failed project. I would say so. It's like the sum of things which effect requirements
budget time time we and could be everything just from the wrong people for the
job people get sick people get on vacation, customer changes his mind,
Misunderstanding and difficult communication and it's a long list of factors which
basically have an effect on the a project success which eventually effect project as
success.
32 Adham I see yeah. OK. So maybe this a bit repeated question but do you thing that risk
management prevent software failure and how?
33 I2 Just by itself. I think it cannot prevent failure or guarantee to prevent failure. But I
think it is an important tool in every project to assure or reduce the probability is
that something fails, to increase the probability that it is a success, and most of it
is to take measures early before something goes really bad. And I think the most
important point of it is to keep the customer on track and updated all the time
because the worst thing is for customers if there is a surprise. If you promise one
thing and then a long time later you come and you come up with something

54
 completely different. If he's part of that trip and he is with you when you hit the
wall and then you work together to climb over it. And he's with you still on the
same page. And then he can forgive a lot of issues differences in the budget
difference in the time difference in the requirements as long as he see the
increment between changes is not too big. If It's a small increment and usually
you can have a successful project which may fail according to the standards you
said at the beginning of the project but if you do active risk management and what
I want is whatever risk management is not something do in the beginning of the
project and then you are done, it something you need to do constantly in the
meeting calls constantly in the gold chain. So you need to check out the how's it
going.
34 Adham Are you saying it is dynamic?
35 I2 Dynamic part of every spring every day something that deviate in form. If it is a
larger deviation question ask the customer he needs to be with you in his state of
mind.
It needs to shift gradually like the approach shifts and if you if you like start here
you say you want to go here and then you end up here if you didn't update the
customer he will by this difference be chocked but if you like this and the
customer follows you all the time and isn't much for a difference, then he is not so
chocked that you end up somewhere up. and they like this estimation re-
estimation and re-assessment where we are where we want to be, can we still
reach it on time budget money and things? This is what risk management does.
36 Adham also while we making our literature review we've found some indications that
management has a negative impact on project success is that possible solution.
37 I2 I guess that risk management in this case. Has been badly performed, or It was the
wrong type of risk management. Well I don't know about this case and in what
context how justified they are risk management has a bad impact but I could
imagine that when you overdo it.
If it's a small project where you don't need it or you don't need it in that extent that
it may make you slower as it needed. it could be that you may be draw wrong
conclusions where you make the customer panic without any reason and he maybe
stops the project as you just told me you can’t make it. But maybe you could do it
but you just got wrong assessment so it could maybe not lead to a complete failure
of a project. It could maybe increase the cost. Of course you need to do. Though
it’s a kind of investment but it also assure that the cost stays lower and helps
managing that. Usually I see it more from the point of view don't have risk
management and it has a negative impact.
38 Adham That is what you see it
39 I2 And usually this happens when things don't go, and you don’t see it early enough
and then trick risk management is makes you feel good for one or two or three
sprints, then you are a little bit relaxed. You don't follow your routine and
suddenly you come back from vacation and its chaos. So this is the thing it's
active you need to search for issues, deviation you need to get it all in the team
and its culture. That people report how is it going. So if you ask how is it going

55
 not just always sound going good. If people always tell you this, then it’s bad it’s
a trick its not going good
40 Adham So it is the communication?
41 I2 It is the communication it’s how people maybe behave how they think what
culture they have what background they have. Could have a lot of a lot of things
that I could think if somebody just comes in is somebody gets a task to do risk
management on this project. People did not talk not body up to. What does it
mean? How do we do it? And they could actually make it stop the project or put
more risk on the success, and if it's done in the right way and the right way may
change from project to project.
42 Adham So it differs?
43 I2 Yeah
44 Adham OK. We move a bit forward. So these are criteria that have been defined in the
literature as project success criteria’s on a scale between one to five where 1 is
strongly disagree and 5 is strongly agree long distance of three or five years. Do
you think that risk management help in meeting user requirments?
45 I2 Yes, strongly agree
46 Adham Completing the project? Project was not cancelled?
47 I2 Aaaaaaa strongly agree, I think when its cancelled it’s a failed project can we still
economically the best choice but politically then it’s a failed project for one or
other reason.
48 Adham Completing the project on budget?
49 I2 Yes, I agree
50 Adham Completing the project on time?
51 I2 This is in the middle natural. Usually on time it is there it is part of the success but
that is usually most of the people can relax. I have not seen a project where
somebody would have died if he did not deliver on time the. And we didn't have
any projects where we had to pay fines if we didn't make it on time frame for him.
We could manage that and the customer and they were flexible.
52 Adham But does risk management help you meeting that?
53 I2 I think agree, risk management helps to stay on time
To stay on time I think it's just part of the rules are just and it's the nature of
closing meetings
54 Adham High quality software? Software well tested software?
55 I2 I agree as well it should help there because this is a risk that might hit later, even
thought the initial face is done and maybe the next one, but risk management
should tell you to which extent you need to test. So I agree.
56 Adham I see
57 Adham Final system works as intended?
58 I2 I agree as well
59 Adham Customer satisfaction?
60 I2 Neutral
Somehow I think risk management it may, yes of course some of it but sometimes
customer satisfaction depends on other things. And you may not be able to tackle
with risk management alone.

56
61 Adham I just want to clarify one point from you, you are saying to me that risk
management, has maybe no direct relation with high quality or it has
62 I2 Yeah
63 Adham Because as you say you deliver more than the time need so I can imagine you do
less testing?
64 I2 Maybe a consequence of risk management that you recommend, let’s to meet the
time schedule, let’s do less testing, and we fine with the bugs we have in the
system. aaa a risk management I would maybe put this as neutral.
65 Adham Now we come to the last question. This one we already got an answer for.
In your opinion, do all projects require a risk management process, yes or no?
66 I2 Yes. Even if the project is simple
67 Adham Even if it is simple?
68 C2 Yes even that, at least you have thought a thought about it. It does not need to be
formal you do not need to have an explicit risk manager, you maybe don’t have a
concept follow up on stuff. But at least it tell you I have defined budget, time,
resource, and that is already in your head, and I think this is some kind of risk
management. I think no project where you do not do it.
69 Adham So it comes naturally?
70 I2 It comes natural, But How formal is it, to what extent, how developed it is. That
depends on the project. And in larger project it is more important
71 Adham I see, well those were my questions, do you have anything else to add?
72 I2 Mmmm I think not right it was interesting, am curios on the results
73 Adham Me too actually
74 I2 Let me know when it is ready.
75 Adham Sure, so we thank you for giving us the chance
76 I2 Cool, thank you

57
Third Interview
Type of interview: Skype video call
City: Jönköping Sweden

Interviewer: Adham El-Ahmad

Interviewee: I3 (for the anonymity of the interviewees, names and working place are removed)
Table E.3: Transcription of interview 3
Speaker
1 Adham so we would like first of all to thank you for giving us the chance to perform this
interview with you, and we would like also to inform you that every data will be
collected here will not be public and will be used for our own purpose.
2 I3 Ok
3 Adham So we would like to know your name, what organization you are work at, and
what is your role? Also how many workers do you have at the company?
4 I3 My name is ….. I work at … as a project leader, and we are six persons
5 Adham Ok, your level of education and how many years of experience do you have?
6 I3 I have a bachelor degree, and have been working for one year
7 Adham One year, we would like to know how do you define a successful project? What
are the key characteristics for a successful project?
8 I3 Happy staff and happy customers. When the project ends and both the customers
and the staff is happy then you have done it right
9 Adham Ok, happy staff and happy customers, I will right this down
10 Adham Ok, so the second question is
11 I3 Wait, back to the first question usually it tends to not never happen. You either
get happy staff or happy customer, not both.
12 Adham Ok
13 I3 Yeah
14 Adham From your definition to project success, and you are saying happy staff and
happy happy happy customer, do you think that risk management contributes to
these two criteria?
15 I3 The risk management part are really interesting, because I think that is
something we should always apply at a certain level. It depends what work you
do, if it is a simple job that takes a week then it is not worthy because it takes as
much time to do the assessment that you need to do. And but if it is a long
project then as always you might save yourself a lot of trouble, time, and money
by doing the real assessment and think about it. I would recommended at least
one meeting every week for at least 15 minutes where you go through your plans
for the week.
16 Adham Ok, but do you think that these meetings can ensure to you having a happy
customer?
17 I3 Oh yeah yeah, of course, because when you are alone working on your thing,
you may. It is really hard to think out of the box. If I create an app that is I said
that the UI looks awesome to me, it looks clear and it is easy to understand blah

58
 blah blah. But that is only to me as someone who has never used it before and
might feel nauseous witnessing that, what is this, what is happening, what is it
doing I don’t understand. you know it is confusing to.
Also sometimes you, it is easy to steer away from the goal because you other
staff that you might need to do, so those meeting and the risk assessment you
have helps to prioritize what is most important for me to finish this week
18 Adham Ok
19 I3 Which part of the project do I need to do first so that I can go on to the next part
and so on.
20 Adham And how does risk management then ensure happy staff?
21 I3 One second
22 Adham How does risk management ensure happy staff?
23 I3 Oh the staff is happy, when you do this assessment and because the customer
usually does not understand the amount of work if it if it is actually a five hour
work or if it is a 50 hour work to do this little thing this little a security detail to
whatever you are working on, this little script as a project leader or a manager,
you can aa you surely understand that this is not going to happen over the same
day or the next 10 minutes. These assessments are really important so that the
staff to keep them happy they have to say the word, what they think about and
how they think about the project so that you can communicates this to the
customer.
24 Adham I see, so you are saying that the risk management gives you the possibility to
communicate with the staff and then with the customer.
25 I3 Exactly, or the other way around.
26 Adham Ok
27 I3 Because sometimes the customer would come and say yeah we would like this
to be finished this week. And also what we had planned before, and in those
cases usually this is how we answer. You say no that is not going to happen.
28 Adham How do you define software development risk or software project vulnerable
risk, please could you give us examples on risks that lead to project failure?
29 I3 Oh bad assessment or no assessment or in a project with big enough or even in
small projects. I have seen small projects for on first look you would think that
would take top 20, 30 hours to finish, but it escalates really quick. Because when
you give the customers the idea that you can finish it within the week but that is
in the best-case scenario, you have to teach your customer what are the
differences between best case and a worst-case scenario. And that the latter one
can happen. You cannot really know plan for everything but you can try to do it,
that is the best thing we can do.
30 Adham Ok , and in your opinion, does software risk management prevent software
project failure? If yes, then how?
31 I3 Oh that is almost the same answer. The project fail when you don’t, when there
is a huge…
this is the best example, when we have several programers working on one

59
 projects doing each part, they usually don’t really know more than the basic staff
of what the other guys are doing.
32 Adham Yes
33 I3 Yeah, putting those parts together can be without enough information, like I can
give you example from last week. I had assumed that the details the API I was
going to work on could handle page request something simple as that, so I sat
there on Friday afternoon the last two hours of work trying to get my script to
work thinking it was my fault that the pagination would not work. The lazy
loading did not work nothing really worked as I planned, and the customer
wanted to have the prototype up, we had two hours to finish. There is a missing
communication of something that should have been done earlier. This is where
we need this site map and the project map of what we are going to do, when we
are going to do it, and how we are going to do it. And it is important as well for
program and its staff that are not really working on some parts to understand at
least to know that this is going to happen and it is going to happen this week or
this sprint the whatever.
34 Adham I see
35 I3 If you do not do this, you end up in situation like that last week.
36 Adham Ok, so many research shows that software risk management has a negative
impact on project success, is that possible? In which situation can that happen?
37 I3 Oh yeah in those small projects, if you have experienced enough programs as
you are back to their project that they have done a hundred times before, if you
force them to assess, and plan and design structure and the behavior of an
application, it might end up taking them a lot a lot more time than just let them
do it. As a manager you have to know when something gets. That is the
manager’s role to understand while we do not really need to do the whole thing
for this, it is enough with this guy, or do I really need to step in there and do my
job as a manager.
38 Adham So you are saying like overdoing it overdoing it can lead to failure.
39 I3 Yeah, imagine if you start your company and you need a site for it, fifty
thousand SEK to spend on it, yeah sure I am going to hire this awesome
company and decent designers that good program must have a good reputation,
and then some new manager comes in and say dude you know what is going to
happen first you need to go to the drawing board and show us all what you are
thinking this is going to take 10 hours extra, because I’m going to have some
input on it and then he have to change that and he and maybe already had if
someone had done this a hundred times before then even if it looks sketchy at
first it is probably going to work anyway. That goal is there, and then the
customer gets a bill that is much much higher than the original plan that is that is
not good for your company’s reputation, and it is not good for the staff
happiness, they don't get the noise that you're toggling with them.
40 Adham so spending extra time on things like overdoing things? Can make you lose
41 I3 Yeah

60
42 Adham ok the following criteria where identified in the literature as project success
criteria, in a scale from 1 to 5 where 1 is strongly disagree and 5 is strongly
agree how can you assess those:
does risk management ensure meeting user requirements?
43 I3 Strongly agree
44 Adham Ok, does risk management ensure completing the project meaning that the
project was not cancelled?
45 I3 Five
46 Adham Five, I will have to write this here so I would remember, does risk management
ensure completing the project on budget?
47 I3 Agree
48 Adham Agree four
49 I3 Yeah
50 Adham Ok, completing the project on time
51 I3 Four
52 Adham Four
53 Adham High quality software like having a solid and well tested system
54 I3 Five, this where risk management shines this is where you can really put all your
ideas to test before you try to implement them, risk management ensures that.
55 Adham Ok, we will have to cover this point later on, and does risk management ensure
that final system works as intended?
56 I3 Five
57 Adham Five, and does it ensure customer satisfaction?
58 I3 Five
59 Adham Describe how actually you were think some point we have already answered on
but some other points like you are saying to me that risk management ensures
that you having high quality software.
60 I3 Yeah
61 Adham How is that possible?
62 I3 Oh, high quality is objective depending on whose you are asking right, if you
ask a programmer if you ask a designer, or if you ask a customer depending on
who you are going to ask their opinions might be a little bit different. I’m
thinking in general terms that risk management, lets lets go with a bigger project
something that takes a few months to finish to make sure that the end goal is the
same for everybody, this is where risk management helps a lot.
63 Adham I see
64 I3 want to know what is going to happen, what can happen and what shouldn’t
happen and what can we do to avoid this thing. Should that happen. Some time
you have to also, this is the hard part when you know that you are going to do it
the hard way but then you knew it before hand, because you have this meeting
you have this assessment, and this is risk management in a big big projects like
Triple A games like the games that have 200 staffs when they create them and

61
 they have free years to finish them, then this is crucial I think. Yeah it is really
really really worth it.
65 Adham I see, and in your opinion do all projects require a risk management process
66 I3 No not all no no no of course not, if you know your team and you know what
they are capable of, if you know that you are stepping in and doing that to a
certain degree you have, ok to a certain degree yes.
67 Adham So could you give examples of projects that does not do not require risk
management
68 I3 As I said small sized, small mobile apps, something that is quick because it is all
about time because time is money, keeping schedule is keeping customer’s
clients happy and you don't want to be in the office with risk management where
it is unnecessary.
69 Adham I see
70 I3 Yeah, this the part of the manager’s job or the project leader
71 Adham Ok, do you have any thing that you would like to add?
72 I3 Yeah sure, when you start in maybe year or may be tomorrow…. That first thing
that you should do is that all the time is learn to know your staff, this is crucial,
really really important, to know what they like is more important than knowing
what they can do, when they like to do they will do it with pride, aah so just that.
73 Adahm I see
74 Adham So we would like to thank you again and thank you for giving us the chance to
meet you
75 I3 No worries thank you
76 Adham Thank you

62
Fourth Interview
Type of interview: Phone call
City: Lund Sweden - Stockholm Sweden

Interviewer: Adham El-Ahmad

Interviewee: I4 (for the anonymity of the interviewees, names and working place are removed)
Table E.4: Transcription of interview 4
1 Adham Ok so we would like first of all to thank you for giving us this chance to
interview you and to get to know from your experience about software risk
management. As a start could you please introduce yourself, you name, the
company working at and your years of experience.
2 I4 Ok so my name is … I am a project manager at …, I have 15 years working
experience in total, and 10 years as a project manager
3 Adham Ok, so if we start with the questions, how do you define a successful project?
What are the characteristics for a successful project?
4 I4 Ok, so apart from the most classical definition, which is on time on budget and
within scope of functionality. We can also say that a successful project when
you have a happy and a proud team of what they have delivered also a happy
customer.
5 Adham Ok, from your definition to project success, do you thing that risk management
contribute to the success criteria’s you mentioned, like on time on budget,
meeting requirements and happy team and happy customer?
6 I4 Yeah I think that risk management, helps you staying on track and to know what
is going on with the project, what kind of problems do we have so we ensure to
solve them and ensure the quality of the product. And talking to the customer
and updating and letting him know how things are going, and what kind of
challenges do we have during the project.
7 Adham Ok, so if we move on, how do you define software development risk? Please
give examples of software development risks that could lead to project failure?
8 I4 Mmm, I think the most dangerous one is the changing of requirements. Because
this one lead to exceed the time and the budget, it also could affect the quality,
since you keep trying to meet the requirements, and it mind up with a system
that has bugs.
9 Adham Ok if we move on, in your opinion does software risk management prevent
software failure? If yes, then how?
10 I4 No, I don’t really think so. Risk management helps you in defining and
estimating the risks you have during the development, but I wouldn’t say that it
prevents failure.
11 Adham Ok, so the next question is some research show that risk management has a
negative impact on project success, is that possible? in which situations?
12 I4 Yeah I think when you do not involve the customer in your risk management
process, so that the customer does not get to say his word about the risks he
thinks that might exists, so you start working while you have risks hidden on
customer’s side

63
13 Adham Ok I thought that risks comes from the company itself, from the development
team. I didn’t know that the customer should be involved in this as well.
14 I4 All stakeholders should be involved, so of course the customer should be
involved as well, he is the product owner, and he has to say his word, and be
aware of the requirements if he keeps changing them.
15 Adham Ok if we move one, the following criterias were identified in literature as a
success criteria’s. On a scale between 1 to 5 where 1 is strongly disagree and 5
is strongly
Does risk management ensure
16 Adham Meeting user requirements?
17 I4 I would say 4 agree
18 Adham Completing the project, project was not cancelled.
19 I4 Four
20 Adham Completing the project on budget?
21 I4 Four
22 Adham Completing the project on time?
23 I4 Four
24 Adham High quality software ( having a well-tested system)
25 I4 Here I would say three
26 Adham Final system works as intended
27 I4 Four
28 Adham And customer satisfaction
29 I4 Four
30 Adham So we already talked about requirements, time and budget, and how the final
system should be but I would like an explanation of why you gave high quality
three?
31 I4 I think that high quality is something hard to achieve when you have
requirements that changes all the time, sometimes you would deliver the project
even you know it has a low quality.
32 Adham Even if you know?
33 I4 yes this is mostly done upon customer request when they need there project no
matter what, and that they are not willing to pay more to have the system well
tested, and I don’t think that risk management can help in that.
34 Adham Ok final question, do you think that all projects need a risk management
process? Yes or no?
If no can you give examples of project that do not require a risk management
process?
35 I4 Of course not all projects, like a short project that takes less than two weeks,
then setting for half a day to discuss risks, would be just a waste of time and it is
not really needed.
36 Adham Ok so I think that that was all, is there anything you would like to add?
37 I4 mmm no not today.
38 Adham Ok thank you once again for giving us this chance.

64
39 I4 You welcome.
40 Adham Oh I just forgot to ask you about your level of education? And size of your
company?
41 I4 My level of education, I have bachelor degree, but it has nothing to do with
project management, and we are 215 workers.
42 Adham Ok its just for our statistics
43 I4 Oh no worries
44 Adham Thank you again, bye
45 I4 Thank you bye

65
Appendix F – Interview coding
Table F.1: Interview coding process
Nodes Answers
1 Node 1: I1: ” Risks are everywhere ”
Perception about risk I1: “all project defiantly need a risk management
management plan”
I1: “it might be zero risks, but I still have to
make the plan and write that the chances of this
and this and that risks are almost zero, which
basically means that I have no risks, but I still
need to make the plan”
I2: “if you have a project which doesn't do what
it's supposed to do and its complete failure”
I2:“the most important thing is that it's Within
budget and that's usually the most difficult thing
to get done”
I2:“if you didn't update the customer he will by
this difference be chocked but if you like this
and the customer follows you all the time and
isn't much for a difference, then he is not so
chocked that you end up somewhere up. and
they like this estimation re-estimation and re-
assessment where we are where we want to be,
can we still reach it on time budget money and
things? This is what risk management does”
I2: “Yes even that, at least you have thought a
thought about it. It does not need to be formal
you do not need to have an explicit risk
manager, you maybe don’t have a concept
follow up on stuff. But at least it tell you I have
defined budget, time, resource, and that is
already in your head, and I think this is some
kind of risk management. I think no project
where you don’t do it”
I4: “of course not all projects, like a short
project that takes less than two weeks, then
setting for half a day to discuss risks, would be
just a waste of time and it is not really needed. ”
2 Node 2: I1: “A risk is something that might occur, and
Risk hinder you from achieving your goals”

66
 I2: “That people report how is it going. So if you ask
how is it going not just always sound going good. If
people always tell you this, then it’s bad it’s a trick
its not going good”
I3: “bad assessment or no assessment or in a
project with big enough or even in small
projects.”

3 Node 2.1: I1: “The main problem is change of

Changing requirements, in the Middle East area, from my
requirements experience, I can say that the customer does not
really know what he want. So we start a project
as we think that the customer want, but after a
while and after delivering a part of the system to
the customer, he realize that this is not how he
was thinking, and here the problems start to
come up.”
I1: “if the customer has already changed the
requirements multiple times, but you still want
to deliver the product on time, to have a
customer satisfaction, you will have problems
when it comes to integration testing and that can
lead to delays. So sometimes you will deliver
the product to the customer even that you know
it’s not well tested, and it has bugs. But those
bugs should be within an acceptable level”
I1: “the changing requirements sometimes,
makes you want to deliver the system even with
less quality product as we talked about.
Sometimes you will deliver the system even
with bugs as I said, to avoid any delays”
I 2: “potential issues and most of it comes from
requirements that it's not clear what should you
do.”
4 Node 2.2: I2: “And usually this happens when things don't
Delay in identification go, and you don’t see it early enough and then
of risk the trick risk management is makes you feel
good for one or two or three sprints, then you
are a little bit relaxed. You don't follow your
routine and suddenly you come back from
vacation and its chaos”

67
5 Node 2.3: I1: “one of the problems occur, when you are
Project dependencies waiting for another project to finish, let’s say
that you are working with the government, and
they are working on another project that you are
supposed to come and enhance or add something
on or whatever, usually governmental projects
take a lot of time, this is a big risk here.”
6 Node 2.4: I2: ” if you have a project which doesn't do what
Risk lead to failure it's supposed to do and its complete failure”
I2: “It’s the communication it’s how people
maybe behave how they think what culture they
have what background they have. Could have a
lot of a lot of things that I could think if
somebody just comes in is somebody gets a task
to do risk management on this project. People
didn’t talk not body up to. What does it mean?
How do we do it? And they could actually make
it stop the project or put more risk on the
success, and if it's done in the right way and the
right way may change from project to project”
I4: “I think the most dangerous one is the
changing of requirements. Because this one lead
to exceed the time and the budget, it also could
affect the quality, since you keep trying to meet
the requirements, and it end up with a system
that has bugs.”
7 Node 3: I1: “Risk management helps us in two ways,
RM and successful first identify the risks and avoid them, and give
project us chances.”
I1: “since you identify the risks, and you realize
that this project is going to take extra time, but
as I said before you will work on that extra time,
and make a strategic goals”
I2: “I think it cannot prevent failure or guarantee
to prevent failure. But I think it is an important
tool in every project to assure or reduce the
probability is that something fails, to increase
the probability that it is a success, and most of it
is to take measures early before something goes
really bad”

68
 I3: “the risk management parts are really
interesting, because I think that is something we
should always apply at a certain level. It
depends what work you do, if it is a simple job
that they say wait then it is not worthy because it
takes as much time to do the assessment that
you need to do. And but if it is a long project
then as always you might save yourself a lot of
trouble, time, and money by doing the real
assessment and think about it. I would
recommended at least one meeting every week
for at least 15 minutes where you go through
your plans for the week.”
I3: “These assessments are really important so
that the staff to keep them happy they have to
say the word, what they think about and how
they think about the project so that you can
communicates this to the customer.”

8 Node 3.1: I2: “yes and that the work are said You assure is
Ensuring things in that you have a product owner that have good
place requirements analytics proses that you are
defining your requirements and you're following
them up during the project, And to assure this
You make sure you have the right people in
place for doing this. You may want to make sure
as the customers has the capability of delivering
the requirements”
I2: “that if you ask the customer what do you
want us to do. He can explain it and not have a
fuzzy idea which changes all the time. If you
have this if you have a moving target then it's
also a problem. And then this could result in
more work, wasted work possibly exceeding
budget or time limits.”
I2: “Yes it could allow you in the beginning to
do this and to ensure that things are in place
before you start a project that you would have
the assessment of the project. What do we think?
What budget do we need?”

69
 I3: “I would recommended at least one meeting
every week for at least 15 minutes where you go
through your plans for the week”
I3: “, it is easy to steer away from the goal
because you other staff that you might need to
do, so those meeting and the risk assessment
you have to learn to prioritize what is most
important for me to finish this week”
I4: “Yeah I think that risk management, helps
you staying on track and to know what is going
on with the project, what kind of problems do
we have so we ensure to solve them and ensure
the quality of the product. and talking to the
customer and updating and letting him know
how things are going, and what kind of
challenges do we have during the project”

9 Node 3.2: I2: “informing the customer about this getting

Involving the them signed that the customer is aware of that
customer and at the end there is no big surprise, so he say
this is not what I ordered and am not going to
pay,”
I2: “I think the most important point of it is to
keep the customer on track and updated all the
time because the worst thing is for customers if
there is a surprise. If you promise one thing and
then a long time later you come and you come
up with something completely different. If he's
part of that trip and he is with you when you hit
the wall and then you work together to climb
over it. And he's with you still on the same page.
And then he can forgive a lot of issues
differences in the budget difference in the time
difference in the requirements as long as he see
the increment between changes is not too big.”
I2: “It needs to shift gradually like the projects
shifts and if you if you like start here you say
you want to go here and then you end up here if
you didn't update the customer he will by this
difference be chocked but if you like this and the

70
 customer follows you all the time and isn't much
for a difference, then he is not so chocked that
you end up somewhere up”
I4: “all stakeholders should be involved, so of
course the customer should be involved as well,
he is the product owner, and he has to say his
word, and be aware of the requirements if he
keeps changing them.”
10 Node 3.3: I3: “The project fail when you don’t, when there
Involve Staff is a huge…
this is the best example, when we have several
programers working on one projects doing each
part, they usually don’t really know more than
the basic staff of what the other guys are doing.”
11 Node 3.4: I2: “it something you need to do constantly in
Dynamic risk the meeting calls constantly in the gold chain.
So you need to check out the how's it going”
I2: “dynamic part of every sprint, every day
something that deviate in form. If it's a larger
deviation question ask the customer he needs to
be with you in his state of mind.”
I2: “It needs to shift gradually like the projects
shifts and if you if you like start here you say
you want to go here and then you end up here if
you didn't update the customer he will by this
difference be chocked but if you like this and the
customer follows you all the time and isn't much
for a difference, then he is not so chocked that
you end up somewhere up. and they like this
estimation re-estimation and re-assessment
where we are where we want to be, can we still
reach it on time budget money and things? This
is what risk management does.”
12 Node 3.5: I2: “I guess that risk management in this case.
Negative Impact Has been badly performed, or It was the wrong
type of risk management. Well I don't know
about this case and in what context how justified
they are risk management has a bad impact but I
could imagine that when you overdo it. ”

71
 I2: “If it's a small project where you don't need it
or you don't need it in that extent that it may
make you slower as it needed. it could be that
you may be draw wrong conclusions where you
make the customer panic without any reason and
he maybe stops the project as you just told me
you can’t make it. But maybe you could do it
but you just got wrong assessment so it could
maybe not lead to a complete failure of a
project. It could maybe increase the cost. Of
course you need to do it. Though it’s a kind of
investment but it also assure that the cost stays
lower and helps managing that. Usually I see it
more from the point of view don't have risk
management and it has a negative impact.”
I3: “in those small projects, if you have
experienced enough programs as you are back
to their project that they have done a hundred
times before, if you force them to assess, and
plan and design structure and the behavior of an
application, it might end up taking them a lot a
lot more time than just let them do it”
I4: “Yeah I think when you do not involve the
customer in your risk management process, so
that the customer does not get to say his word
about the risks he thinks that might exists, so
you start working while you have risks hidden
on customer’s side”
13 Node 3.5.1: I1: “Risks are everywhere, there is a risk that the
Overdoing electrical power might cut for a whole year. But
what is the chances for that risk to occur?
Almost zero. But if you keep talking and
analyzing about that risk and thinking that I
must have a backup generator before starting the
project, then you are getting busy with it instead
of working on other more important points.”
I3: “the customer gets a bill that is much much
higher than the original plan that is that is not
good for your company’s reputation, and it is

72
 not good for the staff happiness, they don't get
the noise that you're toggling with them”
14 Node 4: I1: “Risk management is all about identifying
RM prevent failure risks and analyzing and measuring their severity.
Depending on their severity you will make a
plan, and a backup plan, that in case they occur,
you know what to do. Instead of just working
with no idea of what you are going to face.”
I2: “just by itself. I think it cannot prevent
failure or guarantee to prevent failure”
I4: “No, I don’t really think so. Risk
management helps you in defining and
estimating the risks you have during the
development, but I would not say that it
prevents failure. ”
15 Node 5: I1: “A successful project is a project that meets
Success criteria the user requirements, and it does not exceed its
budget and time with more than 25%. However,
this is not always the case.”
I1: “I mean sometimes it is acceptable to exceed
the budget even with more than 25%, if I meet
other strategic goals.”
I1: “strategic goal which is getting a new
customer, which will bring to us more projects.”
I2: “a successful project it's basically, that it is
does what it’s supposed to do is meet the
requirements.”
I2: “The second is that it's in budget”
I2: “the third is its time and means delivered
within the deadline we have.”
I3: “happy staff and happy customers”
I3: “when the project ends and both the
customers and the staff is happy then you have
done it right”
I4: “apart from the most classical definition,
which is on time on budget and within scope of
functionality. We can also say that a successful
project when you have a happy and a proud
team of what they have delivered also a happy
customer.”

73
16 Node 5.1: I1: “Five”
Completing the I2: “I agree”
project on budget I3: “Agree”
I4: “four”
17 Node 5.2: I1: “Five”
Completing the I2: “I agree”
project on time I3: “Four”
I4: “Four”
18 Node 5.3: I1: “Four”
Customer Satisfaction I2: “Neutral.”
I3: “Five”
I4: “Four”
19 Node 5.4: I1: “Five”
Completing the I2: “Five”
project (project was I3: “Five ”
not cancelled) I4: “Four”
20 Node 5.5: I1: “Five”
Final system work as I2: “I agree”
intended I3: “Five”
I4: “Four”
21 Node 5.6: I1: “Three”
High Quality (having I2: “Neutral”
a solid and well-tested I3: “ Five”
system) I4: “Here I would say three”
22 Node 5.7: I1: “Five
Meeting user I2: “Strongly agree”
requirements I3: “strongly agree”
I4: “I would say four agree”
21 Node 5.8: I1: “strategic goal which is getting a new
Strategic goals customer, which will bring to us more projects.”

74
References
Abe, J, Sakamura, K, & Aiso, H (1979), 'An analysis of software project failure', Inspec,
EBSCOhost, [Accessed 3 April 2017].

Ali Munassar, N. and Govardhan, A. (2010). A Comparison Between Five Models Of Software
Engineering. IJCSI International Journal of Computer Science, 7(5).

Andreessen, M. (2011). Marc Andreessen – Why Software Is Eating The World. [online] Genius.
Available at: https://genius.com/Marc-andreessen-why-software-is-eating-the-world-annotated
[Accessed 23 Mar. 2017].

Anil, I. and Thomasson, D., (1991). An empirical investigation of the use of content analysis to
define the variables most prevalent in project successes and failures. In Proceedings of the 1991
PMI Annual seminar/symposium.

Arnuphatrairong, T. (2011). Top Ten Lists of Software Project Risks : Evidence from the
Literature Survey. In: International MultiConference of Engineers and Computer Scientists.

Arshad, N, Mohamed, A, & Nor, Z (2007), 'Software development projects: risk factors and
occurrences', WSEAS Transactions on Computers Research, vol. 2, no. 2, pp. 354-361.

Atkinson, R., & Flint, J. (2001). Accessing hidden and hard-to-reach populations: Snowball
research strategies, Social Research Update, Vol. 33, Available Online:
http://sru.soc.surrey.ac.uk/SRU33.pdf [Accessed 08 April 2017]

Bannerman, PL (2008), 'Risk and risk management in software projects: A reassessment', The
Journal Of Systems & Software, 81, Best papers from the 2007 Australian Software Engineering
Conference (ASWEC 2007), Melbourne, Australia, April 10-13, 2007, pp. 2118-2133,
ScienceDirect, EBSCOhost, [Accessed 4 April 2017].

Barki, H, Rivard, S, & Talbot, J (1993), 'Toward an Assessment of Software Development Risk',
Journal Of Management Information Systems, 10, 2, pp. 203-225, Business Source Complete,
EBSCOhost, [Accessed 4 April 2017].

Base36.com. (2017). Agile & Waterfall Methodologies – A Side-By-Side Comparison | Base36.

[online] Available at: http://www.base36.com/2012/12/agile-waterfall-methodologies-a-side-by-
side-comparison/ [Accessed 29 Mar. 2017].

Baumeister, R. and Leary, M. (1997). Writing narrative literature reviews. Review of General
Psychology.

Bhattacherjee, A. (2001). Understanding Information Systems Continuance: An Expectation-

Confirmation Model. MIS Quarterly.

Boehm, B. (1991). Software risk management: principles and practices. IEEE Software, no. 1, p.
32, IEEE Xplore Digital Library, EBSCOhost, [Accessed 14 March 2017].

75
Boehm, BW (1981), Software Engineering Economics, n.p.: Englewood Cliffs, N.J. : Prentice-
Hall, cop. 1981, Library catalogue (Lovisa), EBSCOhost, [Accessed 21 May 2017].

Boehm, BW (1989), Software Risk Management, n.p.: Washington, D.C. : IEEE Computer Society
Press, cop. 1989., Library catalogue (Lovisa), EBSCOhost, [Accessed 4 April 2017].

Bryman, A, & Bell, E (2015), Business Research Methods, n.p.: Oxford : Oxford Univ. Press, cop.
2015, Library catalogue (Lovisa), EBSCOhost, [Accessed 8 April 2017].

Bukohwo, E (2015), 'Risk Model For Software Development Personnel', vol.I, Inspec,
EBSCOhost, [Accessed 25 March 2017].

Castellansystems.com. (2017). Castellan Systems - Waterfall Management Guide. [online]

Available at: http://www.castellansystems.com/Waterfall.cshtml [Accessed 26 Mar. 2017].

CERPA, N, & VERNER, J (2009), 'Why Did Your Project Fail?', Communications Of The ACM,
52, 12, pp. 130-134, Business Source Complete, EBSCOhost, [Accessed 14 May 2017].

Chaos Report (1995). The Chaos Report 1994. [online] The Standish Group International.
Available at: https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf
[Accessed 23 Apr. 2017].

Cooke-Davies, T (2002), 'The “real” success factors on projects', International Journal Of Project
Management, 20, pp. 185-190, ScienceDirect, EBSCOhost, [Accessed 22 April 2017].

de Bakker, K., Boonstra, A. and Wortmann, H. (2011). Risk managements' communicative effects
influencing IT project success. International Journal of Project Management, 30(4), pp.444-457.

Dedolph, F. (2003). The neglected management activity: Software risk management. Bell Labs
Technical Journal, 8(3), pp.91-95.

De Wet, B. and Visser, J. (2013). An Evaluation of Software Project Risk Management in South
Africa. The South African Journal of Industrial Engineering, Vol 24, Iss 1, Pp 14-28 (2013), 1, p.
14, Directory of Open Access Journals, EBSCOhost, [Accessed 13 May 2017].

DIDRAGA, O. (2013). The Role and the Effects of Risk Management in IT Projects
Success. Informatica Economica, 17(1/2013), pp.86-98.

ENFEI, L. (2015). Risk Factors of Software Development Projects in Chinese IT Small and
Medium Sized Enterprises. Master Level. KTH ROYAL INSTITUTE OF TECHNOLOGY.

Esiefarienrhe Michael, B (2015), 'Risk Model For Software Development Personnel', Lecture
Notes In Engineering And Computer Science, Vol 2215, Iss 1, Pp 195-200 (2015), 1, p. 195,
Directory of Open Access Journals, EBSCOhost, [Accessed 6 April 2017].

76
Frese, R. and Sauter, V. (2014). Improving your odds for software project success. IEEE
Engineering Management Review, 42(4), pp.125-131.

Gallagher, K., (2002). Software Development Risk Management. 2002, CSCI 510 Professor
Report.

Growth. (2017). What is an SME? - Growth - European Commission. [online] Available at:
http://ec.europa.eu/growth/smes/business-friendly-environment/sme-definition_en [Accessed 31
Mar. 2017].

Gupta, D. and Sadiq, M. (2008). Software Risk Assessment and Estimation Model. 2008
International Conference on Computer Science and Information Technology.

Hall, EM (1998), Managing Risk : Methods For Software Systems Development, n.p.: Harlow :
Addison-Wesley, 1998, Library catalogue (Lovisa), EBSCOhost, [Accessed 25 April 2017].

Hashimi, H., Hafez, A. and Beraka, M. (2012). A Novel View of Risk Management in Software
Development Life Cycle. 2012 12th International Symposium on Pervasive Systems, Algorithms
and Networks.

Hijazi, H., Alqrainy, S., Muaidi, H. and Khdour, T. (2014). A Framework for Integrating Risk
Management into the Software Development Process. Research Journal of Applied Sciences,
Engineering and Technology, 8(8), pp.919-928.

HIJAZI, H., ALQRAINY, S., MUAIDI, H. & KHDOUR, T. (2014). Risk factors in software
development phases. European Scientific Journal, 10.

Hutchins, G. (2012). #4 - QUANTIFYING SOFTWARE FAILURE AND DISASTERS - (C)

CAPERS JONES - SOFTWARE@RIS - CERM ® RISK INSIGHTSCERM ® RISK INSIGHTS.
[online] Insights.cermacademy.com. Available at: http://insights.cermacademy.com/2012/09/4-
quantifying-software-failure-and-disasters-c-capers-jones-softwareris/ [Accessed 23 Mar. 2017].

Janjua, U., Jaafar, J. and Lai, F. (2016). Expert's opinions on software project effective risk
management. 2016 3rd International Conference on Computer and Information Sciences
(ICCOINS).

Jugdev, K., Perkins, D., Fortune, J., White, D. and Walker, D. (2013). An exploratory study of
project success with tools, software and methods. International Journal of Managing Projects in
Business, 6(3), pp.534-551.

Junior, R. and Carvalho, M. (2013). Understanding the Impact of Project Risk Management on
Project Performance: an Empirical Study. Journal of Technology Management & Innovation, 8.

KHAN, Q, & GHAYYUR, S (2010), 'SOFTWARE RISKS AND MITIGATION IN GLOBAL

SOFTWARE DEVELOPMENT', Journal Of Theoretical & Applied Information Technology, 22,
1, p. 58, Supplemental Index, EBSCOhost, [Accessed 25 April 2017].

77
Khatavakhotan, A. and Ow, S. (2012). Rethinking the Mitigation Phase in Software Risk
Management Process: A Case Study. 2012 Fourth International Conference on Computational
Intelligence, Modelling and Simulation.

Lewin, MD (2002), Better Software Project Management : A Primer For Success, n.p.: New York
: John Wiley, ©2002., Library catalogue (Lovisa), EBSCOhost, [Accessed 24 April 2017].

Lee, Y.-H., Hsieh, Y.-C. & Hsu, C.-N. (2011). Adding Innovation Diffusion Theory to the
Technology Acceptance Model: Supporting Employees' Intentions to use E-Learning Systems.
Educational Technology & Society. 14(4) p. 124-137.

Linberg, KR (1999), 'Software developer perceptions about software project failure: a case
study', The Journal Of Systems & Software, 49, pp. 177-192, ScienceDirect, EBSCOhost,
[Accessed 21 May 2017].

McConnell, S (1996), Rapid Development : Taming Wild Software Schedules, n.p.: Redmond :
Microsoft Press, cop. 1996, Library catalogue (Lovisa), EBSCOhost, [Accessed 21 May 2017].

Muhsin, M. (2017). The Relationship between Risk Management and the Success of Software
Development Projects.

Muriana, C. and Vizzini, G. (2017). Project risk management: A deterministic quantitative

technique for assessment and mitigation. International Journal of Project Management, 35(3),
pp.320-340.

Murthi, S. (2002). Preventive risk management software for software projects. IT Professional,
4(5), pp.9-15.

Palinkas, L., Horwitz, S., Green, C., Wisdom, J., Duan, N. & Hoagwood, K. (2015). Purposeful
Sampling for Qualitative Data Collection and Analysis in Mixed Method Implementation
Research, Administration and Policy in Mental Health and Mental Health Services Research, Vol.
42, No. 5, pp. 533-544, Available through: LUSEM Library website
http://www.lusem.lu.se/library [Accessed 08 April 2017]

Park, S. Y. (2009). An Analysis of the Technology Acceptance Model in Understanding University

Students' Behavioral Intention to Use e-Learning. Educational Technology & Society, 3, p.150–
162.

Procaccino, J, Verner, J, Shelfer, K, & Gefen, D (2005), 'What do software practitioners really
think about project success: an exploratory study', The Journal Of Systems & Software, 78, pp.
194-203, ScienceDirect, EBSCOhost, [Accessed 21 May 2017].

PROCACCINO, J, & VERNER, J (2009), 'Software Developers' Views of End-Users and Project
Success', Communications Of The ACM, 52, 5, pp. 113-116, Business Source Complete,
EBSCOhost, [Accessed 3 April 2017].

78
Recker, J. (2013). Scientific Research in Information Systems A Beginner's Guide: Springer
Heidelberg New York Dordrecht London.

Reel, J. (1999). Critical success factors in software projects. IEEE Software, 16(3), pp.18-23.

Robson, C (2011), Real World Research : A Resource For Users Of Social Research Methods In
Applied Settings, n.p.: Chichester : Wiley, 2011, Library catalogue (Lovisa), EBSCOhost,
[Accessed 9 April 2017].

Samantra, C., Datta, S., Mahapatra, S. and Debata, B. (2016). Interpretive structural modelling of
critical risk factors in software engineering project. Benchmarking: An International Journal,
23(1), pp.2-24.

Saunders, M., Lewis, P., & Thornhill. (2007). Research Methods for Business Students: Pearson
Education.

Savolainen, P, Ahonen, J, & Richardson, I (2012), 'Software development project success and
failure from the supplier's perspective: A systematic literature review', International Journal Of
Project Management, 30, 4, pp. 458-469, Inspec, EBSCOhost, [Accessed 30 March 2017].

Shane Hastie, S. and Wojewoda, S. (2015). Standish Group 2015 Chaos Report. [online] InfoQ.
Available at: https://www.infoq.com/articles/standish-chaos-2015 [Accessed 18 Apr. 2017].

Simon, D. and Simon, F. (2012). Integrating Test and Risk Management. In: Eighth International
Conference on the Quality of Information and Communications Technology. Cologne, Germany

Sommerville, I (2016), Software Engineering, n.p.: Boston : Pearson, 2016, Library catalogue
(Lovisa), EBSCOhost, [Accessed 6 April 2017].

Singh, Y, & Goel, B (2007), 'A step towards software preventive maintenance', ACM SIGSOFT
Software Engineering Notes (ACM Digital Library), 32, no. 4, p. 10, Supplemental Index,
EBSCOhost, [Accessed 25 April 2017].

Spector, A, & Gifford, D (1986), 'A COMPUTER SCIENCE PERSPECTIVE OF BRIDGE

DESIGN', Communications Of The ACM, 29, 4, p. 268, Publisher Provided Full Text Searching
File, EBSCOhost, [Accessed 18 April 2017].

Tao, Y. (2008). A Study of Software Development Project Risk Management. 2008 International
Seminar on Future Information Technology and Management Engineering.

Testingfreak. (2017). What is V Model in software testing and what are advantages and
disadvantages of V Model. [online] Available at: http://testingfreak.com/v-model-software-
testing-advantages-disadvantages-v-model/ [Accessed 27 Mar. 2017].

79
Vahidnia, S. and Tanriöver, O. (2016). An Evaluation Study of General Software Project Risk
Based on Software Practitioners Experiences. International Journal of Computer Science and
Information Technology.

Van Scoy, R. (1992). Software Development Risk: Opportunity, Not Problem. pittsburgh: Software
Engineering Institute.

Wanderley, M, Jr.Menezes, J, Gusmão, C, & Lima, F (2015), 'Proposal of Risk Management

Metrics for Multiple Project Software Development', Procedia Computer Science, 64, p. 1001,
Supplemental Index, EBSCOhost, [Accessed 14 April 2017].

Waters, J. (2015). Snowball sampling: a cautionary tale involving a study of older drug users,
International Journal of Social Research Methodology, Vol. 18, No. 4, pp. 367-380, Available
through: LUSEM Library website http://www.lusem.lu.se/library [Accessed 25 April 2016]

Wixom, B, & Todd, P (2005), 'A Theoretical Integration of User Satisfaction and Technology
Acceptance', Information Systems Research, 16, 1, pp. 85-102, Business Source Complete,
EBSCOhost, [Accessed 14 March 2017].

Wolfswinkel, J., Furtmueller, E. & Wilderom, C. (2013). Using grounded theory as a method for
rigorously reviewing literature, European Journal of Information Systems, Vol. 22, No. 1, pp. 45-
55, Available through: LUSEM Library website http://www.lusem.lu.se/library [Accessed 08
April 2017]

Yi, M. Y. & Hwang Y. (2003). Predictingthe use of web-based information systems: self-efficacy,
enjoyment, learning goal orientation, and the technology acceptance model. Int. J.Human-
Computer Studies. 59 p. 431–449

80