The Impact of Scope Creep on Project Success: An Empirical Investigation

Abstract

Advocates of software engineering and software project management stated in the literature that creeping of scope is one of the most common causes for the failure of software projects. Also, advocates believed that it could occur in almost every software project, which leads to compromise in quality, delayed schedules, increase cost and decreased customer satisfaction. However, the lack of empirical evidence demands a comprehensive investigation to identify the factors of scope creep and to propose a conceptual framework to empirically evaluate the impact of scope creep on software project success. To determine the scope creep factors in this study, two exploratory methods, i.e. a Systematic Literature Review (SLR) and interview from experts are performed. Following the analysis of these methods, a conceptual framework is proposed. To empirically evaluate the proposed conceptual framework, data is collected through a survey method. Next, the collected data is analyzed through Partial Least Squares’ Structural Equation Modelling (PLS-SEM). From the results, it is evident that the identified factors of scope creep are negatively associated with software project success. The results of empirical evaluation also second the findings of SLR. The outcome of the study may help the practitioners to understand the dynamics of factors, which undermine scope creep in software SMEs and to assist them in the development of effective control and mitigation strategies, therefore, to increase the project success rate.

Full text

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017 1
Date of publication xxxx 00, 0000, date of current version xxxx 00, 0000.
Digital Object Identifier 10.1109/ACCESS.2017.Doi Number
The Impact of Scope Creep on Project
Success: An Empirical Investigation
Bakhtawar Komal1, Uzair Iqbal Janjua1, Fozia Anwar2, Tahir Mustafa Madni1, Muhammad
Faisal Cheema3, Muhammad Noman Malik4 and Ahmad Raza Shahid1
1Department of Computer Science, COMSATS University Islamabad, Islamabad 44000, Pakistan
2Department of Health Informatics, COMSATS University Islamabad, Islamabad 44000, Pakistan
3Department of Computer Science, FAST National University, Islamabad 44000, Pakistan
4Department of Computer Science, National University of Modern Languages, Islamabad 44000, Pakistan
Corresponding author: Uzair Iqbal Janjua (e-mail: uzair_iqbal@comsats.edu.pk).
ABSTRACT Advocates of software engineering and software project management stated in the literature
that creeping of scope is one of the most common causes for the failure of software projects. Also, advocates
believed that it could occur in almost every software project, which leads to compromise in quality, delayed
schedules, increase cost and decreased customer satisfaction. However, the lack of empirical evidence
demands a comprehensive investigation to identify the factors of scope creep and to propose a conceptual
framework to empirically evaluate the impact of scope creep on software project success. To determine the
scope creep factors in this study, two exploratory methods, i.e. a Systematic Literature Review (SLR) and
interview from experts are performed. Following the analysis of these methods, a conceptual framework is
proposed. To empirically evaluate the proposed conceptual framework, data is collected through a survey
method. Next, the collected data is analyzed through Partial Least Squares' Structural Equation Modelling
(PLS-SEM). From the results, it is evident that the identified factors of scope creep are negatively associated
with software project success. The results of empirical evaluation also second the findings of SLR. The
outcome of the study may help the practitioners to understand the dynamics of factors, which undermine
scope creep in software SMEs and to assist them in the development of effective control and mitigation
strategies, therefore, to increase the project success rate.
INDEX TERMS Scope management, scope creep, requirement creep, software project success, partial least
squares structural equation modeling.
I. INTRODUCTION
Every year almost 50-60% of software projects end up in
partial or total failure [1]. Even a few reports indicate a higher
failure rate. According to the 2018 project success report, 70%
of the organizations have faced software failure [2]. As per
project management statistics of the year 2017 [3], the ratio for
the challenging project has increased to 43%. Such that they
are over-budgeted, late or have fewer function or feature than
required. Different studies have provided various factors
responsible for project failure, but scope creep is listed as one
of the most prevalent [1-3]. Scope creep is defined as “any
change in project scope or pressure to deliver more than what
was agreed between customers and vendors initially” [4].
From the definition, it can be stated that scope creep must be
properly managed. That is why in a survey from 60 project
managers it was found that 92% of the projects failed due to
lack of scope creep management [5].
The term scope creeps management can be defined as the
process of controlling/preventing scope creep from happening
in any software project [4]. This lack of scope creep
management was also investigated by the Project
Management Institute (PMI) as the main reason for project
failure. According to their reports, more than 50% of the
software projects have experienced scope creep out of which
33% of the projects were PMI’s top performers [6]. This
percentage of scope creep has increased from 43% to 52% in
the last seven years. This increase in scope creep has led to
serious cost overruns. According to Gurlen [7], scope creep
can cost up to four times as initial development cost. This
implication is also supported by the survey conducted from

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
800 IT managers where 62% of the projects identified scope
creep as the main reason for budget overruns [8].
Although scope creep has emerged as one of the common
reasons for software failure [9-11], surprisingly, the research
attention given to this domain is quite minimal [12]. The
author in paper [13] argues that scope management is the most
neglected domain in software project management. Though
every project manager is sure about three things that are most
likely to happen to every project and scope creep is one of
them [14]. Yet, only 6% of the project managers list scope
creep prevention as a method for risk prevention [15]. Kerzner
supported the arguments stating that negligence and
underestimation of the significance, likelihood, and influence
of scope creep is extensive in both: projects and project
management theory [14].
In the lieu of above-mentioned statistics, it is observed that
scope creep is one of the several factors that have a direct
impact on project success. This implication is also supported
in [16], where authors argue that a project is a successful, only
if it has scope creep less than 10%. However, the software
project may end to be either challenged or failure by increasing
the threshold value of scope creep. From the results obtained
from various reports and surveys, it may conclude that most of
the projects are failed due to negligence of scope creep
occurrence. Organizations are not aware of critical factors
responsible for scope creep, which may lead to serious cost or
budget overruns. Therefore, in this study, we aim to discuss
the factors responsible for scope creep in any software
organization. Identification of these factors can improve the
success rate by preventing the occurrence of scope creep and
by reducing its negative impact on a project.
Project success is one of the most researched topics and
center of attention because it helps to evaluate a project in
terms of cost, quality and schedule [17]. Therefore, the
primary purpose of this study is to assess the impact of scope
creep on project success and propose a framework consisting
of scope creep factors and project success. For the purpose,
SLR and interviews are performed to identify factors related
to scope creep. Next, an empirical investigation of the
proposed conceptual framework has been carried out to
analyze the impact of scope creep factors on software projects.
Given the motivation of this research, following are the
research questions addressed in this study:
RQ1: What are the critical or important factors responsible for
software projects scope creep as identified by literature?
RQ2: What are the critical or important factors responsible for
software projects scope creep as identified in the real-world
practice?
RQ3: What is the nature of features dependency among the
identified critical factors of scope creep?
RQ4: What is the impact of scope creep on software project
success?
The paper is structured into the following sections. Related
work is presented in Section II; Section III discusses the steps
proposed to conduct this study. Section IV discusses the
findings of the study and is followed by a comparison
between the factors identified from two different data
collection methods, i.e. SLR and survey. Section V highlights
the discussion part, and in last, the conclusion of the paper is
presented in section VI.
II. RELATED WORK
Scope creep plays a critical role in determining the project’s
future, , i.e. a success or a failure. In [16], for problem
identification the scope is considered as an additional
measure other than time and budget constraints. For this
purpose, CI (Computational Intelligence) tools were used to
analyze scope with Fuzzy logics added to testify the
properties of scope. Another dynamic approach is proposed
in [18] to study the effect of scope on the project’s quality.
This approach contributed to improving the quality
perspective of a product while working on its scope.
An added contribution was made to provide a distinction
between product and project scope and considered it to be the
critical element in achieving projects success. Moreover, it
was suggested to carry out the scope in a properly controlled
manner to overcome its negative impact [19]. Likewise,
research methodology proposed in [9], contributed to
highlighting the negative effect of the project over-scoping
that causes software failures, quality issues and other risks.
Moreover, the paper somehow identified various factors
responsible for achieving realistic project scope.
While talking about realistic project scope, the role of
project scope creep that may lead to failure must be studied.
That is why a research study conducted by author in [20] that
discussed different issues responsible for project failure was
made a primary source of evidence. On the one hand, the
paper identified the gap or distinction between project
success and failure. On the other hand, the performance was
estimated based on issues already defined. Similar research
was performed by the author in [21] to enlist major project
failure causes. These causes were then analyzed with
comprehensive research on literature and discussed the
degree of complexity related to periodicity, emergence and
non-monotonicity. The study concluded with practical
approaches to deal with these causes and their adverse effects
on the project.
In [13] authors perform SLR to identify different factors to
upgrade the project improvement life cycle. Similarly, an
approach based on the visual representation technique was
proposed to get an overview of project scope in large scale
organizations [14]. Moreover, In the paper [15] author
conducted a research to analyze the practices and other
activities before the procurement process. This study was
made possible by combining Swebok and PMBOK. Besides,
a Case study in [16] was conducted in a distributed
environment to study the effect of unavoidable informal
requirement change. Consequently, a model was proposed to
handle these changes more realistically.
The paper [22] elaborated scope management and change
control practices for complex and large projects. A literature

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
review and an electronic survey was performed concerning
scope definition methodology, change control process,
impact of unauthorized scope creep, and other general
project management issues. Moreover, various factors were
also highlighted that were considered as major risks to
software development. Another paper with a similar context
followed a method of systematic literature to provide a list
of various elements needed for project scope definition.
These elements were then evaluated by using electronic
surveys and was later assessed via different experiments
[23]. Yet added research based on systematic literature
review argued that understanding evolution in project
management helps in understanding the future trends [12].
The research mainly focused on a non-deterministic
perspective rather than an empirical or deterministic
perspective.
As seen in literature, there are several factors which make
an impact on scope creep. For validating the implication, a
case study was performed to understand the effect of the
domain and technological factors on scope creep [24]. The
causes for scope creep confirmed to have a negative impact
on the projects. Surprisingly, still, there was no specific
framework existing for scope creep factors in evaluating
their impact on software project success. Therefore, aim of
this study is to recognize factors that are associated with
scope creep and well along to propose a model to evaluate
impact of identified factors on software project success.
III. PROPOSED METHODOLOGY
A multi-method approach is used to identify scope creep
factors, i.e. SLR and interviews. Following the analysis of the
two methods, a conceptual framework has been proposed.
Next, to validate the proposed conceptual framework survey
method is used to collect data from industry experts. Given
below are the steps involved in multi-method approach of the
study.
A. SYSTEMATIC LITERATURE REVIEW (SLR)
SLR is an evaluation of a formulated question that uses overt
approaches to gather and critically analyze data from the
studies involved in the review process [25]. SLR supports in
searching for existing evidence in an unbiased, transparent and
reproducible way [26]. It evaluates the threat of bias and
quality of evidence in individual studies [27]. Moreover, the
entire procedure of SLR is well documented and reported.
Various researchers for respective domains have proposed
different ways of conducting SLR. In this study, guidelines
recommended by Barbara Kitchenham [28] are followed.
TABLE I
SLR PHASES
These guidelines are structured as a three-step process, as
presented in Table I.
1) PLANNING PHASE
The steps involved in the planning phase are discussed as
follows:
1.1 RESEARCH QUESTIONS
A research question is the primary step of SLR process. The
research question is modeled to select primary studies and to
excerpt and analyze appropriate information from them. The
research questions pertinent to our research are already
discussed in the introduction section of this paper.
1.2 DATA SOURCES
In SLR, research strategy is a tradeoff among identifying all
the related primary studies without receiving an enormous
amount of false positives. According to our search scope, we
included the research articles from the time period of 2010-
2018. The primary studies were selected from four diverse
electronic databases, i.e. Science Direct, Google Scholar,
Emerald Insights and IEEE explorer. Other electronic
databases were not chosen because of their accessibility
issues. Whereas, the databases mentioned above were easily
accessible to the author.
1.3 SEARCH STRING
All the searches were formulated based on title, keywords and
abstract. The searches took place in October 2018. Search
strings were based on the keywords from the research
questions following PICO guidelines [29]. Boolean operators
“AND” and “OR” were utilized for concatenations between
the keywords. The digital repositories were explored against
the listed search string:
 (“scope creep” OR “change in scope” OR “scope
management” OR “changing scope in a software
project” OR “scope creep management”) AND
(“factors of scope creep”) AND (“increased project
success”)
1.4 INCLUSION CRITERIA
In SLR process, inclusion and exclusion criteria are the basis
for selecting primary studies. It is recommended to devise a
selection criterion beforehand to avoid any biases. Therefore,
we formulated an inclusion and exclusion criteria relevant to
our research:
 IC-1: Selected primary studies must be published
either in a journal or in a conference.
 IC-2: Selected primary studies must be written in the
English language.
 IC-3: The studies lying between 2010 and 2018
should only be considered because scope creep was
highlighted as a leading cause of software failure in
a survey report published in the year 2010.
1.5 EXCLUSION CRITERIA
Following is the exclusion criterion adopted for our study:
 EC-1: Paper whose full text was not available.
Phases
Steps
Planning
Research questions
Data Sources
Search string
Inclusion and exclusion criteria
Quality criteria for study selection
Conducting
Data extraction
Data analysis
Reporting
Quality Assessment
Type of studies
Temporal distribution of selected primary studies

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
 EC-2: The paper collected as duplicated or similar
from different platforms.
 EC-3: Papers which were not related to scope
management
 EC-4: Blogs, posters, slides, and editorials were also
excluded.
Table II presents the number of studies incorporated in SLR
process after applying inclusion and exclusion criteria.
TABLE II
SELECTED PAPERS ON THE BASIS OF RESEARCH CRITERIA
1.6 PRIMARY STUDY SELECTION
A tollgate approach is used to refine studies identified through
the study selection process. Tollgate approach comprises of
five levels as discussed:
 Level 1: Search the relevant studies based on a
search string and inclusion criteria.
 Level 2: Inclusion and exclusion of selected studies
based on title, keywords and abstract.
 Level 3: Inclusion and exclusion of selected studies
based on content accessibility, duplication and
language.
 Level 4: Inclusion and exclusion of selected studies
based on papers relevance to the topic.
 Level 5: Total number of papers included in SLR.
A total of 1087 articles were found based on a search string
and inclusion criteria. An initial screening was performed on
these searches to exclude irrelevant studies or duplicates. The
remaining 225 papers were then assessed against inclusion and
exclusion criteria in detail. Exclusion criteria were defined to
exclude any un-related research. The criteria excepted 28
papers which were not composed in English and whose full
content was inaccessible. The remaining 197 were then
assessed out of which 168 articles were excluded that didn’t
identify the scope creep and were not directly addressing
scope management. A total of 29 papers were included in our
data extraction process. Figure 1. shows the primary study
selection based on the tollgate approach.
FIGURE 1.
Study selection criteria
1.7 QUALITY CRITERIA FOR STUDY SELECTION
The selected studies were evaluated against the criteria
recommended by the Centre for Reviews and Dissemination
(CDR) Database of Abstracts of Reviews of Effects (DARE),
York University [28]. The quality checks based on nine
questions to evaluate the total quality and reliability of
selected primary studies are given below:
 Are the objectives of the proposed research stated
clearly? (Q1)
 Are the scope and context of the proposed study
defined clearly? (Q2)
 Is the proposed solution validated by an empirical
study? (Q3)
 Is the research process adequately documented?
(Q4)
 Are the stated research questions answered? (Q5)
 Are the limitations of the proposed study taken into
consideration? (Q6)
 Do the findings of the research paper clearly state
in terms of credibility, reliability and validity? (Q7)
 Does the conclusion of the article relate to the stated
aim and objectives? (Q8)
 Does the study provide future implications? (Q9)
The quality assessment question was given one of the three
values (0, 0.5, and 1). The studies describing results in favor
of quality assessment question were marked with (1). Studies
which depicted some of the properties were marked with (.5).
While studies that were not related to quality assessment
questions were marked (0). Table III shows the overall score
of quality assessment for each paper.
Sources
Number of
studies
included after
applying
search query
Number of
included
studies after
EC-1 and
EC-2 applied
Number of
included studies
after EC-4 and
EC-5applied
IEEE Xplorer
55
55
9
Science Direct
65
64
10
Google Scholar
39
31
8
Emerald
Insights
66
47
2
Total
225
197
29

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
TABLE III
QUALITY ASSESSMENT SCORE
Quality assessment in SLR is carried out to analyze the
credibility, quality, rigorousness and relevance of reporting
of primary studies. Following the threshold value given in
[51], the primary studies had an overall score higher than
40% were considered for further process. Based on this
criterion none of the studies was left out.
According to the quality assessment scores, 50% of the
selected primary studies were of good quality. Moreover,
each selected primary was assessed individually for its
rigorousness, relevance and credibility. Around 51% of the
studies included in our SLR process exhibited their
significance to the topic under investigation. Similarly, the
findings and results presented in about 58% of the studies
were thorough and precise.
2) CONDUCTING THE REVIEW
The second phase of the SLR process, i.e. conducting the
review is performed to set review protocol into practice. The
steps involved in this phase are discussed as follows:
2.1 DATA EXTRACTION
In addition to the quality assessment, the following
information was also extracted from the selected primary
studies.
 The type of research (SLR, experiment, survey or
case study).
 Publication year
 The sources in which studies were reported (i.e.
journal, conference)
 The factors of scope creep discussed by those
studies.
2.2 DATA ANALYSIS
After performing analysis on all the selected papers, a total
of 13 factors were identified. The factors identified by each
of the chosen primary studies are shown in Table IV.
TABLE IV
SCOPE CREEP FACTORS
3) REPORTING THE REVIEW
After setting the review protocol in practice, reporting has
been performed. The reporting phase comprises of three
steps:
3.1 TYPE OF STUDIES
Five types of studies based on the research methods were
identified during the review processes which are SLR,
experiments, case study, surveys and interviews. According to
Primary studies
Quality
Rigor
Credibility
Relevance
Total
Q
1
Q2
Q3
Q4
Q5
Q6
Q7
Q8
Q9
[16]
1
1
.5
0
1
0
0
1
1
5.5
[30]
1
1
1
1
1
0
1
1
1
8
[18]
.5
1
1
1
1
1
1
1
.5
8
[31]
1
1
1
1
.5
0
0
1
0
5.5
[32]
.5
1
1
.5
1
1
1
1
.5
7.5
[33]
1
1
.5
0
1
1
0
1
1
6.5
[9]
1
1
1
1
1
0
1
1
1
8
[34]
.5
.5
0
.5
.5
1
.5
1
0
4.5
[35]
1
1
1
1
1
1
.5
1
0
7.5
[36]
1
1
1
.5
1
1
1
1
.5
8
[4]
.5
.5
.5
.5
1
0
.5
1
0
4.5
[37]
1
1
1
1
1
1
1
1
1
9
[38]
1
1
1
1
.5
0
0
1
1
6.5
[39]
1
1
1
1
1
1
0
1
.5
7.5
[40]
1
1
1
.5
0
1
0
.5
.5
5.5
[41]
0
1
1
.5
.5
1
0
1
1
6
[42]
1
1
1
1
1
0
0
1
1
7
[43]
1
1
1
1
1
0
1
1
1
8
[22]
.5
1
1
1
1
0
0
1
1
6.5
[44]
1
1
1
1
1
1
0
1
1
8
[23]
1
1
1
1
1
1
1
1
1
9
[45]
1
1
1
1
1
1
1
.5
.5
8
[46]
1
1
.5
.5
1
0
0
1
.5
5.5
[20]
1
1
1
1
1
0
0
1
.5
6.5
[21]
1
1
0
.5
1
0
0
1
.5
5
[47]
1
1
0
1
1
.5
0
1
1
6.5
[48]
1
1
.5
1
1
1
0
1
1
7.5
[49]
1
1
1
1
1
1
1
1
1
9
[50]
1
1
1
1
1
1
.5
1
.5
8
Factors Name
Reference
Frequency
(%)
Rank
Schedule
constraint
[16][30][18][31][32][3
3][9][34][36][37][38][
39][40][41][42][43][44
][45][46][20][21][47][
48][49][50]
25 (86 %)
1
Poor scope
management
[16][30][18][31][33][9
][34][36][37][38][39][
40][41][42][43][44][45
][46][20][21][47][48][
49][50]
24 (82 %)
2
Organizational
capabilities
[32][37][41][46][20][4
9][50]
7 (24%)
5
Lack of knowledge
[32][4][44][45][47]
5 (17%)
7
Policies and
standards
[36][38][22][23][45][4
9]
6 (20%)
6
Requirement
volatility
[16][18][31][32][33][9
][34][35][38][39][42][
45][46]
13 (44%)
3
Lack of resources
[30][9][40][23][47][50
]
7 (24%)
5
Unclear goals and
objectives
[31][34][44][45][47][2
0]
6 (20%)
6
Stakeholder
involvement
[16][18][31][32][38][2
0][21][48][49]
9 (31%)
4
Project complexity
[35][38][22][46][21][5
0]
6 (20%)
6
Communication
gap
[30][31][32][33][45]
5 (17%)
7
Risks
[4][38][40][23][45][46
]
6 (20%)
6
Project size
[18][33][35][37][38][4
0][41][22][44][20][48]
[50]
13 (44%)
3

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
Figure 2, 80% of the studies are empirical studies which are
further divided into interviews (7%), case-studies (31%),
experiments (14%) and surveys (28%). The remaining 20% of
the studies adopted the meta-analysis and SLR process.
FIGURE 2.
Type of study adopted by selected primary studies
3.2 TEMPORAL DISTRIBUTION OF SELECTED PRIMARY
STUDIES
Figure 3 displays the distribution of the selected primary
studies based on publication year. All the selected primary
studies were published in the timeframe of nine years, i.e.
(2010-2018).
FIGURE 3.
Year wise distribution of selected primary studies
3.3 RESULTS AND DISCUSSION
In this section, the results of SLR are presented and discussed
in detail.
An SLR was performed to identify factors associated with
scope creep. Three different participants were involved in the
factor identification process. The whole workflow of SLR
process is displayed in Figure 4. Firstly, the research questions
relevant to our study were formulated. Following this, a
preliminary search was carried out to validate that the idea was
not done before in any protocol or journal. Furthermore, a
search strategy was planned to include studies from four
different databases within the timeframe of 2010-2018. Search
strings were based on title, abstract and keyword following
PICO guidelines. The author validated the search strings from
approving it from the supervisor. A total of 1087 articles were
found based on a search string and inclusion criteria. Tollgate
approach was used to refine studies identified through the
study selection process. A total of 29 studies were included in
our data extraction process. Besides, the selected studies were
evaluated against the quality criteria. Lastly, after performing
the data analysis, 13 factors related to scope creep were
identified.
FIGURE 4. Work flow of systematic literature review
The results obtained after performing data analysis are given
as follows:
1. Both schedule constraint and poor scope
management were found to be the most critical factor
responsible for scope creep with the highest
frequency of 86 % and 82% respectively.
2. Requirement volatility, project size and stakeholder
involvement were the third most repeated factors
responsible for scope creep occurrence.
3. Similarly, 20% of the articles specified unclear goals
and objectives responsible for scope creep in a
software project.
4. In the course of our analysis, 21% of studies
exhibited that resources and communication factors
are a subset of each other. While treating them as an
autonomous factor, communication contributed its
17% of share whereas, resource allocation
contributed 24% of its share in attaining project
success.
5. Whereas, 20-24% of studies highlighted the role of
better organizational policies and capabilities to
reduce the risk related to scope creep.
In order to address the RQ1, a list of factors responsible for
scope creep in any software project is listed by calculating the
SLR
Meta Analysis 31%
28%
7%
14%
Empirical Studies
SLR Meta-Analysis Case study Survey Interviews Experiments
0
2
4
6
8
2010
2011
2012
2013
2014
2015
2016
2017
2018
Number of studies
Year

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
frequency and percentage. Furthermore, using the criteria of
having a percentage ≥50%, a total of two factors were
regarded as critical factors. Table III presents the details of
factors with frequency, percentage, and rank.
To address RQ3, the results from SLR were analyzed to
understand the nature of dependency between identified
factors. A pattern of dependency among the schedule and poor
scope management was observed i.e. the number of studies
encountering poor scope management as a cause for scope
creep has also listed budget constraint as another reason.
Similarly, requirement volatility was reflected as a result of
organizational issues. While analyzing its impact, the study
[52] discovered that managing user requirements and
organizational needs effect on software project success. More
than one-third of the SLR articles talking about requirement
volatility also concentrated on the need for better strategies
and standards for an organization. According to Moneke cause
and effect analysis, [53] systemic problems related to
organizations' capability, procedures and rules can serve as the
enabling factors of scope creep.
According to the author, broad communication, changing
facilitation and knowledge sharing are three main issues that
affect projects' success rate. Likewise, the allocation of soft
skills in software project management relates to management
skills and communication [39]. Hence, we can conclude that
both factors are somehow related to each other.
The authors emphasized that early recognition of scope issues
can lead to project success. Proper scope management is still
not enough to reduce scope creep if project managers
overlook stakeholders' concerns and opinions [50]. Said by
Kerzner [54], failing to understand what is best in the
customers' interest in the initial phase of software
development can result in severe cost overruns. A strong
claim was made by Farok in his study [55] stating that "The
project managers' likelihood of encountering scope creep is
reduced if there is a good understanding of what the
stakeholders wish to see completed".
B. INTERVIEWS
Qualitative data analysis techniques are used to collect and
analyze data through unstructured interviews. The expert
opinion helped us in endorsing the factors obtained from SLR
and to pursuit for any information missed or overlooked.
1) DATA COLLECTION
We gathered data in our investigation from three types of
experts (i.e. industry experts, academic experts, and experts
working in both domain areas). Academic experts were
nominated on the basis of their experience in teaching and
research in software engineering and scope management.
Meanwhile, industry experts were chosen on the basis of their
expertise in software development. The data gathered from
these experts led us to acquire a detailed understanding of the
subject. Table V displays the demographic information.
TABLE V
DEMOGRAPHIC INFORMATION OF EXPERTS
2) CONTENT ANALYSIS
Content analysis is the process of analyzing qualitative data
(interview’s text data) to derive an explanation for a particular
phenomenon [56]. The qualitative analysis starts with
collecting data. This collected data is then organized and
analyzed to derive conclusions on the theme of the research.
Qualitative data analysis helps in understanding the purpose
and objectives by revealing ideas and patterns in data [57]. As
our study was exploratory; hence, opting for pure grounded
theory was not appropriate.
However, we used three different coding techniques to
make the content analysis more rigorous and significant. The
coding techniques included in our study were: open, axial and
selective coding. This strategy is also followed by other
researchers to get significant results for their studies [58].
3) QUALITATIVE ANALYSIS AND RESULTS
The main reason for adopting open coding was the emergence
of concepts from the raw data that are later grouped into
conceptual categories [59]. Open coding was used to identify
categories of transcribed interviews. In the course of the open
coding phase, codes were assigned to words/group of words
that were relevant in the context of our research. Relevant
codes were identified from the data analysis and were labelled
accordingly. Initially, 80 codes were obtained from in-line
coding. These codes were then compared with other codes
within and across the interviews. Pertinent open codes were
grouped in the form of categories.
Based on open, axial and selective coding, we identified three
categories. The categories were named as a technological
component, organizational component and human
component.
3.1 TECHNOLOGY COMPONENT
The first main category that has been identified is the
technology component. The analysis showed that the first
main category comprises of 8 factors; technological
constraints, change in market needs, requirement volatility,
project complexity, risks (known/unknown), project size and
poor scope definition as tabulated in Table VI.
Expert
Experience
Position
Expertise
1
13
CEO/Assistant
Professor
Academia +
Industry
2
18
Assistant Professor /
Team lead
Academia +
Industry
3
12
Lecturer/CEO
Academia +
Industry
4
6
CEO
Industry
5
18
Assistant Professor
Academia

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
TABLE VI
TECHNOLOGY COMPONENT
Item
Factors
Expert Opinion
Industry +
Academic
Industry
Academic
1
2
3
4
5
F1
Schedule Constraint




F2
Poor scope definition



F3
Technological Constraints



F4
Change in market needs


F5
Requirement Volatility





F6
Project complexity

F7
Risks

F8
Project size

The categorization of the factors was also supported by the
work of [41], where authors defined technology component as
a “combination of different factors such as development
environment, scope, project complexity, process models, FP
count, and programming languages.”
3.1.1 SCHEDULE CONSTRAINT (F1)
Schedule constraint is one of the most common factors
responsible for scope creep occurrence. According to [40],
every project has a predetermined deadline that is based on
different factors such as resource availability, customer
requirements and project feasibility, etc. The amount of time
increased for the development process also impact the project'
budget and scope. The decided schedule for the project is
directly associated with the number of resources required and
set of requirements needed to be part of the scope.
3.1.2 POOR SCOPE DEFINITION (F2)
During the development of a software project, scope
management plays an important role. According to Greiman
[60], a too broad scope statement can serve as a basis for scope
creep. The report is further emphasized by Farok and
Carkenord [55] [61], which indicates that scope creep can
occur because of poorly defined scope either by the project
managers or the customers. This is also evident in the quotes
from interviews:
“According to our local industry, scope creep refers to unclear
scope or misunderstanding of scope [Interviewee 3]
“The major changes and modifications within the scope of
software project that affect project's schedule, budget, quality
and layouts lead to scope creep” [Interviewee 4]
Most of the times, customer don’t precisely know what they
want the system to work like. This lack of knowledge can
result in misinterpretation of scope. The unclear scope can
further lead to frequent addition of requirement.
3.1.3 TECHNOLOGICAL CONSTRAINT (F3)
In conjunction with other factors, the technological constraint
can also trigger scope creep in any software project as stated
by our experts:
“The main cause of scope creep is technological barriers, cost,
and timeline, skills of our resources, requirements,
stakeholder interest and client's need. …. In scope creep, we
look into modifications whether they are because of
technology, process, team skills, cost or requirements.”
[Interviewee 4]
“If risk analysis is not carried out properly, feasibility is not
properly checked, use of new technology of which
programmers are not familiar can trigger scope creep in any
software project” [Interviewee 3]
Some of the times the technical methods used are novel or
the techniques in use are outdated while the project is still in
progress. In such scenarios, the changes in scope should be
incorporated to update the system.
3.1.4 CHANGING MARKET NEEDS (F4)
Every so often, changes in scope are related to schedule and
cost overruns.
On the contrary, “changes in any dimension of iron triangle
(cost, schedule and quality) are because of change in market
conditions that could temp to scope changes.”
[Interviewee 5]
Whenever, a client is faced with changing market conditions,
he could witness his business prospects changing. In turn the
expectations from the project’s result will also be adapted. For
example, if the market is expected to shrink, the client may
choose to neglect or omit a part of the project’s scope [62].
3.1.5 REQUIREMENT VOLATILITY (F5)
Another most recurring factor in our study was requirement
volatility. According to [63], requirement volatility can be
defined "as any change or growth in project's requirement
specification". It is essential to mention here that requirement
volatility contributed as a critical factor in project failure
according to chaos report [37]. Most of the studies during our
SLR also stated requirement volatility as a term associated
with requirement creep or scope creep. The requirement
addition/modification/deletion is narrated by all the
interviewees as one of the significant scope creep factors that
have a direct influence on software project success. The
implication can be understood from the quote’s excerpts
below:
“Scope creep can be defined as augmentation in the project’s
requirements through the lifecycle” [Interviewee 5]
“For me it is an addition of requirements which were unknown
or beyond the scope in the beginning and the redefinition of
same requirements which were earlier defined in another
way.” [Interviewee 1]
Our interviewed experts also highlighted that frequent changes
in requirement can lead to cost and schedule overruns.
3.1.6 PROJECT COMPLEXITY (F6)
A significant number of studies established that by assessing
project complexity and project size in initial phases helps in
decreasing the negative impact of scope creep and can

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
facilitate in achieving project success. According to Varajão
[50], megaprojects (complex and substantial projects) are
more disposed to scope creep. It is because of the complexity
and sheer size, which usually involves rework to some extent.
Similarly, the nature of scope creep is also complexity and size
dependent.
As per our interviews’ findings:
“In some cases, scope creep is preventable and in some cases
it is not. It depends on the size and complexity of the project”
[Interviewee 4]
3.1.7 RISKS (F7)
As per our analysis, the risk is an important factor in scope
creep such that if the risk is not properly managed/analyzed,
scope is rapidly increased and changed. Risk is a potential
problem that may or may not occur in the future. It is mostly
caused by lack of information, time or control. The risk is
multifaceted; it can be a growth in production cost or
development of poor-quality software or can be inadequacy to
complete the project on time.
3.1.8 PROJECT SIZE (F8)
Jorgensen in his study [64] states that large-sized projects lead
to overconfidence in estimating realistic achievements. This
statement is further emphasized by Hussain [65] in his study,
implying that there exists an inverse relationship between the
size of the project and the direct cost of scope creep. As
discussed earlier, the nature of scope creep either is
preventable or not is dependent on the size of the projects. For
example, one of the interviewees stated that:
“To me third option is true that means, scope creep is both
preventable and inevitable. This depends on the stage of the
project, nature and size of project, expertise involved,
resources available” [Interviewee 5]
During our analysis phase, we came to know that 80-90% of
the time scope creep occurs in a software project. Most of the
times, scope creep targets the large scale projects but
practically can occur in project of any scale, also mentioned
by the interviewee:
“Scope creep has occurred in almost every project but most of
the times they occur in large scale project [Interviewee 2]
“Scope creep can occur in almost every project either they are
of smaller scale or larger but talking specifically in Pakistani
context, 90% of the times scope creep occurs in government
projects.” [Interviewee 1]
3.2 HUMAN COMPONENT
The second main category identified during our analysis is the
human component. The division comprises of 5 factors;
change request, client’s lack of knowledge, vendor’s lack of
experience, low customer satisfaction, personnel, low
stakeholder involvement as listed in Table VII.
TABLE VII
HUMAN COMPONENT
As per existing literature, the said category is defined as “a
component that is a composite of number of developers, their
soft skills, technical expertise, and experience of the
developer” [61].
3.2.1 CHANGE REQUEST (F9)
Ideally, whenever a project is started in any software house,
the scope is locked down first. However, in practice, a client
review scope by evaluating software of different competitors
and asks to change specific requirement. This change in
requirement after locking down scope can cause a lot of
difficulty for vendors. Iterations, change set, and change
requests are the drivers responsible for scope creep in any
software project.
3.2.2 CLIENT’S LACK OF KNOWLEDGE (F10)
Insufficient knowledge of the client has a significant
influence on the scope of the software project. The change
request after locking down scope due to lack of their
understanding can cause a project to suffer from quality issues,
delayed schedules and cost overruns. This can be understood
from the research article [66], where the author suggests that
scope creep can occur by inexperienced clients and
stakeholder’s without proper knowledge of projects’ technical
processes.
3.2.3 DEVELOPER’S LACK OF EXPERIENCE (F11)
According to Chesterman [67], lack of requisite experience
and skills results in project failure. Proper scope management
is still not enough to minimize scope creep if project managers
ignore stakeholders’ concerns and opinions [60]. Said by
Kerzner [54] , failing to understand what is best in the
customers’ interest in the initial phase of software
development can result in serious cost overruns. A strong
claim was made by Farok [55] in his study stating that “The
project managers’ likelihood of encountering scope creep is
reduced if there is a good understanding of what the
stakeholders wish to see completed”
3.2.4 PERSONNEL (F12)
The number of employees in an organization can contribute
much to decide the fate of that organization. The staff of an
organization should have relevant soft skills, expertise and
experience. The capabilities of the staff/employees are
Item
Factors
Expert Opinion
Industry +
Academic
Industry
Academic
1
2
3
4
5
F9
F10
F11
F12
F13
Change request


Client’s lack of knowledge

Developer’s lack of
experience

Personnel

Low Stakeholder
involvement



This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
strongly associated to process efficiency and final product
quality.
3.2.5 LOW STAKEHOLDER INVOLVEMENT (F13)
During our analysis, it was found that customer satisfaction
is a dimension used to evaluate project success rate. However,
the author in his study [68] proposed that low stakeholder
involvement or stakeholder’s ignorance of project scope can
lead to scope creep. Failing to add relevant stakeholders in the
planning phase and disagreement imposed by internal
stakeholders plays a vital role in aiding stakeholder’s related
scope creep [61]. As mentioned by our experts:
“Emergence of disagreements among the stakeholders and
Intentional lack of client side involvement are enlisted as the
major causes for scope creep occurrence in any software
project” [Interviewee 5]
Stakeholders and sponsors might consider scope creep as a
definite entity. This positive entity can add value to the project
or provide with better ways to perform tasks that could solve
a problem [69]. However, these change requests and
incremental idea-generation can leave project managers to fail
to consider the possible long-term effects the ideas and
changes can have [14].
3.3 ORGANIZATION COMPONENT
Based on the detailed analysis, the organization component is
identified as the third main category. The category consisted
of 4 factors; lack of resources, organizational capabilities,
unclear goals/objectives and poor communication, as shown
in Table VIII. TABLE VIII
ORGANIZATION COMPONENT
Item
Factors
Expert Opinion
Industry
+
Academic
Industry
Academic
1
2
3
4
5
F14
Lack of resources


F15
Organizational capabilities

F16
Unclear goals/objectives

F17
Poor communication

Madhuri [41] in her paper defined organizational
component as a combination of “factors related to
organizations standards, organization’s domain proficiency
and organization maturity”.
3.3.1 LACK OF RESOURCES (F14)
Lack of resources is yet another issue responsible for project
failure. The lack of resources in any project can prevent us
from meeting our project goals. This lack of resources can be
due to lack of proper estimates or may be due to organizational
changes or may be caused by the lack of stakeholder
commitment.
3.3.2 ORGANIZATIONAL CAPABILITIES (F15)
In a study proposed by Moneke [53], management process,
organizational capabilities, standards and policies serve as the
enabling factor of scope creep that can eventually harm the
project. Shirazi [70] further explained this by including
external and internal changes as the main reasons for scope
creep. These internal and external changes are caused by
communicative dissonance between stakeholders and project
managers. According to our experts:
“In some cases, scope creep is preventable, and in some cases,
it is not. It depends on the size of the project, complexity of the
project, nature of the project, type of stakeholders,
organizational structure, budgeting and timeline.”
[Interviewee 2]
3.3.3 UNCLEAR GOALS AND OBJECTIVES (F16)
Every project and product has some goals, objectives and
needs. The project meeting its goals is considered as the most
critical item for portfolio management efficiency. Projects
with clearly defined objectives and goals are proven to be a
dimension for project success. Ward, in his study [71] stated
that the goals and objectives of a particular project should be
well understood by all its stakeholders. If a goal is unclear
the project is a failure
3.3.4 POOR COMMUNICATION (F17)
Poor communication can result in creating a void that has
to be filled by project managers. These autonomously
suggested changes from the project team can be observed as
unwanted or un-authorized by most of the stakeholders
involved. Miscommunication can occur by a project
manager’s aversion of saying no to clients, stakeholders or
project team members [72]. Low stakeholder involvement in
combination with a lack of proper communication plan plays
a vital role in increasing the probability of scope creep by
generating indecision and ambiguity.
C. TRIANGULATION OF FACTORS OBTAINED FROM
SLR AND INTERVIEWS
For proposing a conceptual framework, it was necessary to
identify every factor related to scope creep. Initially, SLR was
performed to identify factors. During the analysis of selected
primary studies, we identified 13 factors that were repeated in
most of the studies. Moreover, the findings also highlighted
the need of accommodating other factors of scope creep. To
serve the purpose, the list of factors was extended by
employing industry experts. Interviews were conducted to get
an expert opinion on the identification of scope creep factors
to check if any factor is missed in previous steps. During the
qualitative analysis of this study, several new factors of scope
creep were identified. These factors were mostly related to
client and vendor’s participation throughout the project life
cycle. The newly added factors to existing lists were “change
request initiated by the client”, “client’s lack of knowledge”,
“vendor’s lack of experience”, “personnel”, “low stakeholder
involvement” and “technological constraint”. Hence, we can
argue that if a project conforms to its customer satisfaction and

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
function the way it is expected, [40] the quality of a project
improves. Finally, the project is a success.
After confirming the factors of scope creep from the
experts, the selected primary studies were reviewed again to
add literary evidence to the study. In our study,
methodological triangulation was performed within
qualitative methods. Methodological triangulation uses
multiple quantitative and qualitative methods to investigate
the subject. If the conclusion obtained from each of the method
is same we can say that the validity is established. The process
of triangulation was a sequential implementation i.e. the
results from different research methods were gathered in
phases. Triangulation helped us in using two different research
approaches to get fuller, richer results of the study. The
importance of using triangulation in research studies is also
highlighted by Flick in his study. According to the author,
triangulation is a strategy to validate results in order to
increase its consistency, scope and depth [73].
Table IX on the next page provides a complete list of factors
discussed by both the methods, i.e. SLR and interviews.
TABLE IX
DATA ANALYSIS OF SELECTED PRIMARY STUDIES
Ref.
Number
Publication
Year
Paper Type
Identified Factors impacting scope creep in a software project
Technology component
Human Component
Organization component
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
F14
F15
F16
F17
[16]
2011
Conference





[30]
2015
Conference




[18]
2013
Journal





[31]
2013
Journal







[32]
2014
Conference






[33]
2010
Conference





[9]
2012
Journal





[34]
2010
Conference




[35]
2013
Journal



[36]
2017
Journal





[4]
2010
Conference



[37]
2016
Journal





[38]
2015
Conference







[39]
2016
Conference




[40]
2018
Journal




[41]
2014
Conference



[42]
2017
Conference


[43]
2011
Conference


[22]
2012
Conference




[44]
2016
Journal




[23]
2018
Journal






[45]
2015
Journal





[46]
2016
Journal





[20]
2016
Journal





[21]
2013
Journal





[47]
2013
Journal




[48]
2014
Conference




[49]
2016
Journal






[50]
2014
Journal





Expert Opinion
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
F14
F15
F16
F17
Expert 1





Expert 2






This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
D. CONCEPTUAL FRAMEWORK FOR SCOPE CREEP
FACTORS
The core part of our research is the proposed conceptual
framework of scope creep factors and their impact on software
project success, as shown in Figure 5. The proposed
framework provides a list of factors responsible for scope
creep in software projects. The factors presented in the
proposed framework were obtained by conducting SLR.
These factors were then extended by employing experts for
their opinion on said topic.
The scope creep factors identified in this study were
integrated into three main categories to analyze their impact
on software project success. According to existing literature,
organizations can improve their financial performance, their
productivity and can increase their market shares through
successful project execution [17].
The main aim of identifying the factors in this study is to
give a real insight into how project success can be achieved by
managing scope creep. We would argue that these factors
identified hold for other domains. We have also managed to
bring these factors together to give a much more productive
and multi-faceted definition of scope creep in small and
medium-sized companies.
Therefore, based on the detailed analysis and explanation
provided in this section, the hypothesis can be formulated as
follows:
H1: The technological component is negatively associated
with software project success.
H2: The organizational component is negatively associated
with software project success.
H3: The human component is negatively associated with
software project success.
FIGURE 5.
Proposed conceptual framework
Expert 3









Expert 4






Expert 5








This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
E. EMPIRICAL ANALYSIS OF CONCEPTUAL
FRAMEWORK
The section discusses an empirical investigation of the
proposed framework, which consists of scope creep factors
that have a negative impact on software project success.
1) SAMPLE AND DATA COLLECTION
A survey was conducted to validate identified factors of scope
creep from industry experts using research instruments. The
quantitative research method is defined as “the systematic
investigation of phenomena by gathering quantifiable data and
performing statistical, mathematical or computational
techniques” [74]. The results obtained from the quantitative
analysis are considered reliable and objective by the majority
of the experts and researchers [75].
Based on the findings obtained from SLR and interview, a
close-ended questionnaire was developed. A questionnaire is
a set of pre-defined questions in which participants are
requested to share their opinion on an issue under
investigation. Our survey instrument consisted of three main
sections to measure scope creep and project success.
Furthermore, the questionnaire was used to evaluate the
association between scope creep and project success. The first
section included questions related to demographic
information. The demographic information is, shown in Table
X. In the subsequent part, the independent variable scope
creep was measured using three different dimensions. In the
last section, the dependent factor, i.e. project success, was
measured. The survey questions were evaluated on an ordinal
scale of 0-5 ranging from "No critical contribution" to "most
critical contribution".
An online survey was conducted to collect data for our
quantitative analysis. The study involved professionals
employed in software organizations of Pakistan. The targeted
populations of the survey were project managers, business
analysts, software engineers, quality assurance engineers,
business development managers, software developers and
designers associated with the software industry. The
participation request was sent to the respondents via LinkedIn,
emails and text messages. The survey started on 2nd June
2019. In total, 500 experts were requested to participate in the
study. Of the 500 experts, only 251 responded to the survey.
However, only 250 completed questionnaires were usable.
Non-probabilistic sampling method was adopted. The
minimum sample needed for our study was calculated using G
* Power 3.0 software [17]. It is essential to mention here that
the total number of software organizations registered in
Pakistan is 75,713. The equation resulted in 119 responses.
Hence, the sample obtained from the survey was higher than
the one calculated by the equation, i.e. 119 responses.
2) DATA ANALYTICAL APPROACH
The quantitative data analysis was performed using a variety
of inferential statistical tests, i.e. reliability tests, validity tests
and descriptive statistics. Two different analytical tools were
used to analyze empirical data. First of all, SPSS (Statistical
Package for the Social Sciences) was used to understand the
extent and nature of the relationship between variables. To
serve the purpose, correlation analysis was performed.
Secondly, SEM-PLS approach with WarpPLS 6.0 was used
to test hypotheses. The main aim of using SEM-PLS was its
ability to test several independent and dependent variables
simultaneously [76]. Moreover, it can also estimate the model
with a relatively small sample size and does not require to
fulfil the assumptions of normality and goodness of fit models
[77]. SEM-PLS is inclusive multivariate analysis method used
to measure formative constructs [78]. To add the construct
used in our conceptual model are formative in nature [79] [80].
The method contains two models: a measurement model and
a structural model. The measurement model was used for
showing an association amid latent variables and data obtained
from surveys. Whereas, a structural model is used to assess the
association between latent variables. The sample size used in
this analysis is greater than the suggested sample size, i.e. 100-
150. The proposed sample size is recommended for obtaining
valid results in structural equation modelling [81].
IV. FINDINGS
In this section, the results for empirical analysis of the
conceptual framework are carried out. Moreover, comparison
amongst the findings of SLR and empirical study is also
demonstrated.
1) DEMOGRAPHIC PROFILE OF RESPONDENTS
According to [82], a complete analysis of respondents’ basic
information helps in concluding more substantial results.
Thus, the demographic profile of each respondent was
maintained for more authentic and significant results of the
survey. The respondents’ demographic information, including
their working experience, their position and the type of
organization they are being employed is shown in Table VIII.
Most of the respondents involved in this study were project
managers by profession (50.4%). Subsequently, other job
positions were software engineer (17.6%), business analyst
(6.8 %), software developer (12.4%), quality assurance
executive (6%), chief executive officers (3.2%), software
designers (2.4%) and business development officer (1.2%)
respectively. This survey was aimed to collect data from IT
professionals those have related working experience in
software organizations. In this study, (50.4%) of respondents
had working experience of 1-3 years, (33.2%) of respondents
had working experience of 4-7 years, whereas (8.4%) and
(8%) of respondents had working experience of 8-10 years and
more than ten years respectively. In addition, respondents
were asked for the size of the organization they are working
in. In Pakistan, the standard size of employees in small and
medium-sized enterprises (SME’s) is 250. The data in our
research was collected from SME’s recognized in Pakistan. In
this research (46.4%) organizations consist of 10-25
employees, 24.4% of organizations had 26-50 employees,
(19.2%) and (10%) employee ranged from 26-50 and 51-80
correspondingly.

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
TABLE X
DEMOGRAPHIC INFORMATION OF RESPONDENTS
2) QUANTITATIVE ANALYSIS
As mentioned earlier, SPSS and SEM-PLS were adopted for
data analysis. We used a three-step approach in our study. In
the first stage, the proposed model is assessed for correlation
and factor analysis. Pearson product-moment r correlation was
performed to analyze survey data while 'Spearman's rank-
order correlation was performed to determine the significance
of the variance amongst factors identified by SLR and
empirical study. In the next stage, the measurement model is
assessed for reliability and accuracy of the construct. Whereas,
in the third and the last step structural model is assessed for an
association between constructs. Bootstrapping function in
WarpPLS 6.0 software was used to test the hypotheses.
3) CORRELATION ANALYSIS
Pearson product-moment r correlation, sometimes called a
Pearson correlation, is used to measure the linear relationship
among two variables. Pearson correlation is denoted by "r"
when it is measured in the sample. Pearson's r can vary from
+1 to -1. An r of value +1 specifies a perfect positive
relationship, 0 shows no linear relationship between variables
whereas, -1 denotes a negative correlation.
As evident from the findings of SLR and interviews, the
scope creep factors have a negative impact on software project
success. Thus, before running factor analysis, it is
recommended to reverse code items that have a negative
impact so that high value represents the same kind of response
on every item. Recoding variables transforms the original
variable into a new variable without changing it. In our study,
two variables of software project success were recoded:
decreased customer satisfaction and quality issues. The scale
for each item was transformed to a reverse scale such that the
ordinal scale which was originally 5 for ""Extremely
Contributive"", 4 for ""Very Contributive"", 3 for
""Noticeably contributive"", 2 for ""Moderately
Contributive"", 1 for ""Slightly Contributive"" and 0 for ""Not
Contributive at all"" was transformed to a new scale. The
reverse scale was represented as (0 = “Extremely
Contributive”, 1 = “Very Contributive”, 2 = “Noticeably
contributive”), (3 = “Moderately Contributive”, 4 = “Slightly
Contributive”, 5 = “Not Contributive at all”).
After recoding items, the correlation was performed for
each category individually to analyze its impact on project
success's measuring variables. To assess the correlation
coefficient, 'Cohen's standard was used. According to Cohen’s
standard, value between 0.10-0.29 denotes a weak correlation;
the value between 0.30-0.49 specifies a moderate association
and 0.50 or higher denotes a strong association [78].
TABLE XI
CORRELATION ANALYSIS OF TECHNOLOGY WITH PROJECT SUCCESS
Increased
schedule
Increased
budget
Quality
issue
Decreased customer
satisfaction
F1
.027
.020
-.214
-.085
F2
-.010
-.122
-.145
-.020
F3
-.080
.006
-.259
.009
F4
-.118
-.037
-.383
-.059
F5
-.051
-.039
-.271
.000
F6
-.058
-.069
-.233
-.079
F7
-.114
.065
-.170
-.157
F8
-.115
-.077
-.145
-.143
TABLE XII
CORRELATION ANALYSIS OF HUMAN WITH PROJECT SUCCESS
Increased
schedule
Increased
budget
Quality
issue
Decreased customer
satisfaction
F9
-.013
-.048
-.271
-.022
F10
-.016
-.017
-.053
-.016
F11
-.013
-.048
-.271
-.104
F12
-.065
-.052
-.139
-.105
F13
-.063
-.119
-.210
-.039
TABLE XIII
CORRELATION ANALYSIS OF ORGANIZATION WITH PROJECT SUCCESS
Increased
schedule
Increased
budget
Quality
issue
Decreased customer
satisfaction
F14
-.031
-.004
-.172
-.081
F15
.001
-.018
-.062
-.004
F16
-.083
-.039
-.120
-.114
F17
-.181
-.058
-.237
-.142
From Table XI, we can interpret that most of the factors in
the technology component depicts a negative correlation with
the measure of software success. Therefore, an increase in the
value of one factor can decrease the value of the correlated
factor. Meanwhile, some of the factors showed a positive
correlation with some of the measuring factors of scope creep.
For example, an increase in the pre-determined deadline can
increase the cost. Similarly, other components also showed a
Respondents characteristics
Percentage
Position
Designer
Developer
Chief Executive Officers
Project Managers
Business Analyst
Software Engineer
Quality Assurance Executive
Business Development Officer
2.4%
12.4%
3.2%
50.4%
6.8%
17.6%
6%
1.2%
Working experience (years)
1-3 years
4-7 years
8-10 years
More than 10 years
33.2%
50.4%
8%
8.4%
Number of employees in your organization
10-25 employees
26-50 employees
51-80 employees
81-250 employees
46.4%
19.2%
10%
24.4%

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
pattern of negative correlation amongst the measuring
variables; see Table XII and Table XIII.
4) FACTOR ANALYSIS
In order to reveal the underlying latent variables or factors,
Exploratory Factor Analysis was performed. EFA helped in
explaining the association within number of observed items.
According to Hayton [83], factor analysis is performed on a
sample size of 100 or more. Therefore, our sample i.e. 250 has
satisfied the requirement of minimum sample size required for
EFA. “Kasier-Mayer-Olkin (KMO) and Barlett’s test of
sphericity” was performed. According to the results KMO
sample adequacy value was .729 and Barlett’s test of spericity
was .000 (i.e. p<0.001) confirming that factor analysis is
appropriate. According to Rasheed [84] , if KMO sample
adequacy value is ≥ .6 and Barlett’s test of spericity value is ≤
.5 then the factor analysis is appropriate. It is also
recommended that items having factor loading less than .50
should be eliminated but in our case all the items had their
factor loading greater than .50. Table XIV, shows the results
for EFA. TABLE XIV
FACTOR ANALYSIS OF IDENTIFIED FACTORS
5) MEASUREMENT MODEL ANALYSIS
Before conducting hypothesis testing, the measurement model
displayed in Figure 6 was evaluated first to test its reliability
and validity. The constructs included in our proposed model
are formative. The measurement model consists of three
exogenous constructs identified as technology component,
human component, organization component and one
endogenous construct named as project success. PLS-mode B
alsgorithm was adopted for evaluating the model. The reason
to select this algorithm was its authenticity and strict criteria
for evaluating formative constructs.
FIGURE 6.
Measurement model
Furthermore, the model was assessed for its consistency and
validity. It is reliability tests that measure the goodness of an
instrument. It helps in determining the stability and
consistency of an instrument. In our analysis, we used
Cronbach's alpha and Composite reliability to test internal
consistency. Cronbach's alpha is used for multiple scale item
to determine whether the items included converging or not. In
ideal conditions, the value for both the methods should be
higher than 0.70, but according to [85] [86], the value of 0.60
is also acceptable.
Likewise, convergent validity test was conducted to test the
validity of data [87]. The loading value for convergent validity
should be greater than 0.50 with a p-value of <0.05. Variance
Inflation Factor (VIF) was also acquired to test the validity of
constructs. The value for VIF is acceptable if it is < 5 and is
ideal if it is < 3. It is evident from the results of the validity
and reliability tests (as shown in Table XV and Table XVI)
that the basic criteria for both the tests were met. Therefore,
the data obtained from the instrument was fit for use in further
analysis.
TABLE XV
RELIABILITY AND VALIDITY TEST RESULTS
Construct
item
Min factor
loading
Composite
reliability
Cronbach’s
alpha
Technology
8
≤0.794
0.796
0.711
Human
5
≤0.700
0.790
0.668
Organization
4
≤0.746
0.721
0.677
Variables
Items
Component
1
2
3
Technology
Tech-1
.676
Tech-2
.668
Tech-3
.586
Tech-4
.679
Tech-5
.621
Tech-6
.646
Tech-7
.631
Tech-8
.562
Human
Hum-1
.710
Hum-2
.644
Hum-3
.575
Hum-4
.557
Hum-5
.707
Organization
Org-1
.578
Org-2
.535
Org-3
.554
Org-4
.624

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
TABLE XVI
CONVERGENT VALIDITY TEST RESULTS
Note: the values for p < 0.05, and VIF’s < 2.5 are desirable
for formative indicators
6) ASSESSMENT OF THE STRUCTURAL MODEL
The structural model was evaluated to determine the impact of
exogenous variables on endogenous variable. In this study,
scope creep factors categorized as technology, organization
and human component were hypothesized to have negative
impact on project success. The results of hypotheses testing
were determined by its p-values, path coefficients, effect sizes
and standard errors. A detailed description of the hypotheses
testing results are displayed in Table XVII.
The results of hypothesis 1 show that the path coefficient of
Tech---> Pr_Success is -0.196, the p-value are < 0.001, and
the effect size is 0.060. The results show that the technology
component was negatively associated with project success and
supports the hypothesis. The second hypothesis also predicted
the existence of a negative relationship between organizational
component and software project success. It can be seen that
the path coefficient Org---> Pr_Success is -0.104, the p-value
is 0.047, and the effect size is 0.025. The results support the
hypothesis. However, the value for effect size indicates that it
is weak, as stated by Sholihin and Ratmono [71] effect size
can be categorized into three groups: weak (0.02), medium
(0.15), and substantial (0.35). The testing of hypothesis 3
regarding the relationship between human component and
project success was shown by the path coefficient of Human-
--> Pr_Success being -0.140, the p-value is <0.012, and the
effect size is 0.035. These results indicate that human
component was negatively associated with project success and
support the hypothesis. Hence, hypothesis 1, 2 and 3 are
empirically confirmed. From the results, we can interpret that
technology has a medium effect size on project success,
whereas, human and organization component has a weak
effect size.
TABLE XVII
HYPOTHESIS TEST RESULT
In addition to above mentioned tests, the structural model was
also assessed against global fit indices. These global indices
were calculated in WarpPLS 6.0 that the model was
statistically valid as shown in Figure 7.
All the measures and values for each index are given below:
 Average path coefficient (APC)=0.144, P=0.005
 Average block VIF (AVIF)=1.436, acceptable if <=
5, ideally <= 3.3
 Average full collinearity VIF (AFVIF)=1.500,
acceptable if <= 5, ideally <= 3.3
 Tenenhaus GoF (GoF)=0.256, small >= 0.1, medium
>= 0.25, large >= 0.36
Given by [88], the values for APC is considered significant if
it is lower than 0.05. As evident from the results, the value
calculated for APC in our model is lower than 0.5, so we can
say that our framework is statistically significant. Similarly,
AVIF and AFVIF are also calculated for our study. On the
basis of suggested criteria, the value for AVIF and AFVIF is
ideally less or equals to 3, but values less than 5 are also
acceptable. In our study, the values calculated for AVIF
(1.436) and AFVIF (1.500) fulfils the recommended criteria.
Finally, Tenenhaus GoF is calculated to analyze the
descriptive power for the conceptual model. The values for
Tenenhaus GoF lies in between three sets: small that ranges
from >= 0.1, the value for medium set should be >= 0.25,
whereas for large t should be >= 0.36. As per obtained results,
our model satisfies the criteria for the medium threshold value.
The structural model was measured to conclude the impact of
exogenous variables on the endogenous variable. In this study,
scope creep factors categorized as technology, organization
and human component were hypothesized to have a negative
influence on project success. The results of hypotheses testing
were determined by its p-values, path coefficients, effect sizes
and standard errors. It is imperative to indicate here that our
model consist of independent factors that are statistically
significant but have low R-squared value. As explained by
[89], a good model can have low R-squared value. If we have
statistically significant variable with low R-squared value, we
can still draw conclusions about the relationship among
variables. A detailed description of the hypotheses testing
results is displayed in Figure. 7.
Variables
Items
Loading*
P-Value
Weight
Type
VIF
Technology
Tech-1
0.569
<0.001
0.207
Formative
1.227
Tech-2
0.540
<0.001
0.197
Formative
1.203
Tech-3
0.794
<0.001
0.289
Formative
2.375
Tech-4
0.622
<0.001
0.227
Formative
1.214
Tech-5
0.719
<0.001
0.262
Formative
2.453
Tech-6
0.533
<0.001
0.202
Formative
1.293
Tech-7
0.453
<0.001
0.165
Formative
1.177
Tech-8
0.287
<0.001
0.105
Formative
1.154
Human
Hum-1
0.670
<0.001
0.312
Formative
1.260
Hum-2
0.630
<0.001
0.293
Formative
1.225
Hum-3
0.627
<0.001
0.292
Formative
1.198
Hum-4
0.649
<0.001
0.302
Formative
1.244
Hum-5
0.700
<0.001
0.325
Formative
1.298
Organization
Org-1
0.398
<0.001
0.398
Formative
1.102
Org-2
0.297
<0.001
0.297
Formative
1.045
Org-3
0.467
<0.001
0.467
Formative
1.188
Org-4
0.402
<0.001
0.402
Formative
1.125
Path
Coefficients
P-
Values
Effect
sizes
Decision
Tech--->
Pr_Success
-0.196
<0.001
0.060
Supported
Org--->
Pr_Success
-0.104
0.047
0.025
Supported
Human--->
Pr_Success
-0.140
0.012
0.035
Supported

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
FIGURE 7.
Structural model
A. COMPARISON OF SLR AND EMPIRICAL STUDY
RESULTS
The results obtained from empirical study and SLR was
compared to determine similarities and dissimilarities between
three datasets. The comparison of factors identified during
SLR, interviews and survey are shown in Figure 8.
FIGURE 8.
Comparison between findings obtained from SLR, interviews
and empirical study
From the figure 8, it can be observed that many of the
factors are correlated with each other. Therefore, in order to
determine the significance of the difference between factors
identified by SLR and empirical study, we conducted
Spearman’s rank-order correlation.
Spearman’s correlation coefficient was found to be 0.526,
indicating a moderate positive correlation between the
rankings obtained from the SLR and the empirical data, shown
in Table XVIII.
TABLE XVIII
SPEARMAN CORRELATION COEFFICIENT
Empirical
SLR
Spearman’s
rho
Empirical
Correlation
coefficient
1.000
.526
Sig. (2-tailed)
.
.017
N
20
20
SLR
Correlation
coefficient
.526
1.000
Sig. (2-tailed)
0.17
.
N
20
20
V. DISCUSSION
According to the Standish group report, only 16% of the
software projects are considered successful, i.e they are
competed within time and budget. Meanwhile, for larger
companies the rate for successful project completion is
reduced to 9%. These statistics are evident of the fact that the
rate for project failure has increased in last five years [90]. This
consistency in software failure rate is impacted by several
factors and scope creep is one of them. Therefore, a
comprehensive research was carried out to understand the role
of scope creep on software project.
In this study, authors have investigated the impact of scope
creep factors on project success for software organizations by
employing qualitative and quantitative research approaches. It
is evident from results of SLR that the organizations have to
face adverse consequences due to scope creep occurrence. To
validate the implication, interviews and survey were
performed to explore practitioners’ point of view. The
participants of the survey agreed that the most leading cause
of scope creep is poor scope definition. The implication is also
supported by one of the previous existing studies where the
unclear scope is considered as the main reason for scope creep
[14]. This unclear scope is because of frequent changes in
requirement specification that are not agreed upon or are
approved. As stated in [54] unapproved and non-documented
changes, without following any coordinated approach makes
it challenging to control scope. This unclear scope can lead a
project in unintended directions, causing scope creep.
The findings of SLR and interviews indicated that along
with the poorly defined scope, schedule constraint and
requirement volatility could also trigger scope creep in any
software project. As per chaos report findings, requirement
volatility is enlisted as the main factor to project failure [91].
Whereas in [4], scope creep is defined as any uncontrolled
change in the project’s requirement. In this study, several new
factors were identified which were not stated in literature. The
newly identified factors were mostly related to client and
vendor’s participation throughout the project life cycle.
Although, several factors responsible for scope creep
occurrence were identified however, the results and opinion of
adopted approaches varied from one another to state the most
critical factor of scope creep. To answer the RQ2 critical
factors were determined following the most suggested criteria
given in [82], therefore, factors having frequency ≥ 50 was
considered significant. A total of three factors were identified
as the most critical factors: schedule constraint, unclear scope
and requirement volatility.
Secondly, the factors identified during SLR and interviews
depicted a pattern of dependency. Therefore, we analyzed
survey data by examining the Pearson product-moment r
correlation to state relationship among variables. To evaluate
the correlation coefficient, Cohen’s standard was used. From
our analysis, we interpreted that technological component had
a moderate association with the human component (0.49) but
had a strong relationship with the organizational component
0
20
40
60
80
100
120
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
F14
F15
F16
F17
SLR Interview Survey

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
(0.52). Meanwhile, the human component has a moderate
association with both the components with (0.49) for
technology and (0.47) for the organizational component.
As mentioned earlier in this study, the evidences available
in the literature were not strong enough to state the exact
relationship of scope creep factors. Therefore, we conducted
the same Pearson correlation test separately on each factor to
understand its association with other variables. In practice,
formative indicators can covary, i.e. formative indicators can
correlate but are not interchangeable [92]. According to the
results, requirement volatility was the only factor in
technology component that depicted a moderate association
with an unclear scope and changing market needs. The finding
also seconded by the author in his study, where he strongly
claims that changing requirement can result in scope changes
[93]. The remaining factors in technological component
indicated a weak association amongst them. Similarly, factors
classified under the organizational component and human
component depicted weak association with one another.
While analyzing the association of factors in human
component, an exciting pattern of association was observed.
All the factors of human component showed their association
with quality issues. Such that client’s lack of knowledge, low
stakeholder involvement, lack of developer’s soft skills and
expertise are inversely proportional to the quality of the
project. To comprehend it more openly, the evidences
available in the literature are extracted. In [55] author indicates
that low stakeholder involvement in formulated project scope
could result in scope creep. The suggestion is also supported
by [35], where the client’s lack of knowledge about technical
aspects, of the system which in turn can affect the overall
quality of the system.
The conceptual framework has also been presented in this
study to analyze the impact of scope creep project success. The
conceptual framework along with its hypothesis was tested
empirically using different quantitative analysis techniques to
answer RQ4. The proposed framework consisted of three
exogenous variables: technological component, organization
component and human component that will have a direct
influence of endogenous variable i.e. project success. The
hypotheses for our conceptual framework were tested using
PLS-SEM. The outcomes are evident that technology
component have a negative impact on project success. Such
that increase in any one of the factors from said component
can result in reducing the success rate.
Although the technology component was negatively
associated with project success but one of its factors: schedule
constraint was positively related with endogenous variable.
The study infers that there is adequate indication to conclude
that increase in schedule constraint can lead to schedule and
cost overrun. As mentioned by [14], poor cost and schedule
management can result in cost overruns and project delays.
Similarly, based on our empirical results, increase in
organizational component will have inverse effect on the
project success supporting the hypothesis H2. This shows that
relationship between factors of organization component and
project success is inversely proportional. Various literature
studies also stated that the systematic problems related to
organizational structure are aiding factors of scope creep that
can result in cost overruns, decreased customer satisfaction
and project delays. In addition, the results of the current study
also claimed that the human component also have significant
inverse impact on project success satisfying H3. According to
[36], the assumptions and expectations of client is primary
cause of scope creep that can result in more risk and quality
issues.
From the above discussion, we have concluded that
organization, technology and human factors have a significant
impact on project success. Therefore, the factors must be taken
into consideration in to reduce the negative impact caused by
scope creep. These findings are beneficiary for the people
working in software organizations in order to avoid project
failure due to the ignorance of scope creep factors. The
findings are also significant as they are help focus on the most
critical factors related to scope creep.
The results are evident that scope creep factors have a
negative impact on project success. This was also reflected in
the interviews. According to the interviewees, scope creep can
result in delayed project completion, project failure, increased
project cost, demotivated and under pressure team members,
technical staff turnover, dissatisfied client, increased
maintenance cost and compromised quality. However, this
negative impact of scope creep can be managed by developing
contingency plans, slack times and should follow proper
management process to cope up with the problems mentioned
above. At the time, there is no standardized mechanism for
evaluating scope creep particularly, but we can use process
management tools to prevent scope creep from an occurrence.
Moreover, by using agile methods, flexible price contracts and
incremental delivery scope creep can be prevented.
From a theoretical perspective, the current study contributes
to the empirical evaluation of 17 primary factors of scope
creep that can significantly affect the project success.
Moreover, the conceptual framework, along with its
hypothesis has been developed, which specifies the impact of
scope creep on project success. Secondly, it gives the
viewpoint of practitioners’. Lastly, it performs a quantitative
investigation to validate the framework on a larger sample of
software companies. The results of the empirical research will
be helpful in to overcome the negative consequences of scope
creep, and it may also reduce the project failure rate in
Pakistan.
VI. CONCLUSION
The main objective of this study was to identify the critical
factors of scope creep, which can cause software project
failure. For the purpose, two different exploratory data
collection methods, i.e., SLR and interview, were used. From
SLR, a total of 13 factors were identified from a total of 29
primary studies. Meanwhile, from interviews, taken from 5
experts, a total of 4 new factors were identified which were not

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
stated in the literature. After an in-depth qualitative analysis of
primary studies and interview data, all identified factors were
classified into 3 formative constructs. To empirically
investigate the significance of identified factors, a conceptual
framework was proposed. On the proposed conceptual
framework, the researchers developed the three research
hypotheses. To test the developed hypotheses, a survey was
conducted. A total of 250 practitioners participated in the
study. Following the analysis of collected data, it has been
observed that all the identified factors have a significant role
in scope creep. Furthermore, analysis of data also revealed that
these factors significantly decrease the software project
success. Following the outcome of the study, it is believed that
it can help the practitioners to understand the dynamics of
factors, which undermine scope creep in software SMEs and
also to assist them in the development of effective control and
mitigation strategies, therefore, to increase the project success
rate.
However, this research is limited to small and medium-
sized organizations that execute projects in Pakistan, and
therefore, the findings cannot be generalized. Therefore, for
future study, it is significant to identify the impact of scope
creep on large scale software companies. In addition to
generalize the findings, in future data can be collected from a
different population. Finally, Artificial Neural Networks can
be used in future to overcome the limitation of SEM, i.e.
detection of linear relationships only.
REFERENCES
[1] Project Management Institute (PMI), "Success in Disruptive
Times | Expanding the Value Delivery Landscape to Address the
High Cost of Low Performance PMI's PULSE of the
PROFESSION - 10th Global Project Management Survey,"
Newtown Square, 2018.
[2] Project Management Institute (PMI),"Success Rates Rise -
Transforming the high cost of low performance," Newtown
Square, 2017.
[3] Project Management Institute (PMI), "Pulse of the Profession
2015: Capturing the Value of project management," Newtown
Square, 2015.
[4] C. T. Amoatey and B. A. Anson, “Investigating the major causes
of scope creep in real estate construction projects in Ghana,”
Journal of Facilities Managment, vol. 15, no. 4, pp. 393–408,
Apr. 2017.
[5] A. R. Adam and M. Danaparamita, "Understanding the influence
of poor scope management affecting the successful of an IT
Project," 2016 International Conference on Information
Management and Technology (ICIMTech), Bandung, 2016, pp.
124-129.
[6] Project Management Institute(PMI),"PMI's pulse of the
profession 11the global project management survey," Newtown
Square, 2019, Accessed 20 Jan 2020.[online]. Available:
https://www.pmi.org/media/pmi/documents/public/pdf/learning/t
hought-leadership/pulse/pulse-of-theprofession2019.pdf
[7] K. G. Raman, Meenakshi and V. R. Rajalakshmi, “Effective
Management of Various Forms of Creeping Featurism -“A Little
More”, But Not Anymore”, International Journal of Pure and
Applied Mathematics , vol. 119, pp. 643-656 , 2018.
[8] Project Management Institute (PMI), “PULSE OF THE
PROFESSION ® | 2018 - ‘Success in Disruptive Times |
Expanding the Value Delivery Landscape to Address the High
Cost of Low Performance," Newtown Square, 2018.
[9] E. Bjarnason, K. Wnuk, and B. Regnell, “Are you biting off more
than you can chew? A case study on causes and effects of
overscoping in large-scale software engineering,” Information
and Software Technology, vol. 54, no. 10, pp. 1107–1124, 2012.
[10] S. Neetu Kumari and A. S. Pillai, "A survey on global
requirements elicitation issues and proposed research
framework," 2013 IEEE 4th International Conference on
Software Engineering and Service Science, Beijing, 2013, pp.
554-557.
[11] Neetu Kumari.S and A. S. Pillai, "A study on the software
requirements elicitation issues - its causes and effects," 2013
Third World Congress on Information and Communication
Technologies (WICT 2013), Hanoi, 2013, pp. 245-252.
[12] M. Padalkar and S. Gopinath, “Six decades of project
management research: Thematic trends and future
opportunities,” International Journal of Project Management,
vol. 34, no. 7, pp. 1305–1321, 2016.
[13] J. Moustafaev, "Project scope management: A practical guide to
requirements for engineering, product, construction, IT and
enterprise projects," Auerbach Publications, 2014.
[14] M. Høylandskjaer, “Managerial Perceptions of Scope Creep in
Projects: A Multiple-Case Study,” 2018.
[15] S. Schoonwinkel, “A risk and cost management analysis for
changes during the construction phase of a project,” Journal of the
South African Institution of Civil Engineering, vol. 58, no. 4, pp.
21–28, 2016.
[16] J. M. McQuighan and R. J. H. II, "Scope as a Leading Indicator
for Managing Software Development," 2011 Ninth International
Conference on Software Engineering Research, Management and
Applications, Baltimore, MD, 2011, pp. 235-241.
[17] M. Irfan, M. Hassan, and N. Hassan, “The Effect of Project
Management Capabilities on Project Success in Pakistan : An
Empirical Investigation,” IEEE Access, vol. 7, pp. 39417–39431,
2019.
[18] R. Thakurta, “Impact of Scope Creep on Software Project
Quality,” Vilakshan: The XIMB Journal of Management , vol. 10,
no. 1, pp. 37–46, Mar. 2013.
[19] M. N. Mirza, Z. Pourzolfaghar, and M. Shahnazari, “Significance
of Scope in Project Success,” Procedia Technology, vol. 9, pp.
722–729, 2013.
[20] A. Alami, “Why Do Information Technology Projects
Fail?,” Procedia Computer Science, vol. 100, pp. 62–71, 2016.
[21] K. Wnuk, T. Gorschek, and S. Zahda, “Obsolete software
requirements,” Information and Software Technology, vol. 55, no.
6, pp. 921–940, 2013.
[22] N. Alp and B. Stack, "Scope management and change control
process study for project-based companies in the construction and
engineering industries," 2012 Proceedings of PICMET '12:
Technology Management for Emerging Technologies,
Vancouver, BC, 2012, pp. 2427-2436.
[23] U. Hassan, N. Ahmad, and B. Zuhaira, “Calculating completeness
of software project scope definition,” Information and Software
Technology, vol. 94, pp. 208–233, 2018.
[24] Suma. V Lakshmi Madhuri "Influence of Scope Creep on Project
Success: A Comparative Study between Conventional Approach
verses Agile Approach in Software Development" IEEE
International Conference on Advanced research in Engineering
and Technology (ICARET) 2013 February 8th-9th 2013 Andhra
Pradesh India.
[25] A. Boland, M. G. Cherry, and R. Dickson, Doing a systematic
review: a students guide. London: SAGE, 2017.
[26] M. Hst C. Wohlin T. Thelin "Experimental Context
Classification: Incentives and Experience of Subjects" Proc. 27th
Int'l Conf. Software Eng. pp. 470-478 2005.
[27] J. Zobel, Writing for computer science. London: Springer, 2014.
[28] B. Kitchenham, R. Pretorius, D. Budgen, O. P. Brereton, M.
Turner, M. Niazi, and S. Linkman, “Systematic literature reviews
in software engineering – A tertiary study,” Information and
Software Technology, vol. 52, no. 8, pp. 792–805, 2010.
[29] A. Pollock E. Berge "How to do a systematic review",
International Journal of Stroke, vol. 13, no. 2, pp. 138-156, 2018.
[30] A. Yahya, N. A. Munawar and Y. C. Tuan, “Critical success factor
on e-Government it projects in Brunei Darussalam,” International

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
Journal of Applied Business and Economic Research, vol. 13, no.
9, pp. 6969–6990, 2015.
[31] M. N. Mirza, Z. Pourzolfaghar, and M. Shahnazari, “Significance
of Scope in Project Success,” Procedia Technology, vol. 9, pp.
722–729, 2013.
[32] S. Khankaew and S. Riddle "A review of practice and problems
in RE in small and medium software enterprises in Thailand"
IEEE 4th International Workshop on Empirical RE (EmpiRE),
2014, pp. 1-8.
[33] A. Quispe, M. Marques, L. Silvestre, S. F. Ochoa and R. Robbes,
"Requirements Engineering Practices in Very Small Software
Enterprises: A Diagnostic Study," 2010 XXIX International
Conference of the Chilean Computer Science Society,
Antofagasta, 2010, pp. 81-87.
[34] S. Ullah, A Rauf, A. Shahid and I. Rehman "Scope Management
in Agile Versus Traditional Software Development Methods" in
NSEC Rawalpindi 2010
[35] L. G. Bellenger,“Avoiding scope creep protects the bottom
line,” ASHRAE Journal, vol. 45, no. 10, p. 58, 2003.
[36] A. S. White, “A control model of the software requirements
process,” Kybernetes, vol. 42, no. 3, pp. 423–447, Mar. 2013.
[37] Q. Wang and Z. Song, "Research on optimization of software
development project process based on theory of project
management," 2010 3rd International Conference on Advanced
Computer Theory and Engineering(ICACTE), Chengdu, 2010, pp.
V1-426-V1-430.
[38] K. Wnuk, T. Gorschek, D. Callele, E. Karlsson, E. Åhlin and B.
Regnell, "Supporting Scope Tracking and Visualization for Very
Large-Scale Requirements Engineering-Utilizing FSC+, Decision
Patterns, and Atomic Decision Visualizations," IEEE
Transactions on Software Engineering, vol. 42, no. 1, pp. 47-74,
1 Jan. 2016.
[39] M. A. Saputra and A. A. Arman, "An analysis of software project
management (case study: Government agencies)," 2015
International Conference on Information Technology Systems and
Innovation (ICITSI), Bandung, 2015, pp. 1-6.
[40] K. L. Madhuri, U. M. Mokashi, and V. Suma, “A triangular
perception of scope creep influencing the project
success,” International Journal of Business Information Systems,
vol. 27, no. 1, p. 69, 2018.
[41] K. L. Madhuri and V. Suma, "Influence of domain and technology
upon scope creep in software projects," 2014 International
Conference on Advances in Electronics Computers and
Communications, Bangalore, 2014, pp. 1-6.
[42] R. Sharma, A. J. Sohi, M. J. C. M. Hertogh and J. R. Deketh,
"Controlling the uncontrolled by noticing the unnoticed," 2017
12th International Scientific and Technical Conference on
Computer Sciences and Information Technologies (CSIT), Lviv,
2017, pp. 106 114.
[43] A. J. Nolan, S. Abrahao, P. C. Clements and A. Pickard,
"Requirements Uncertainty in a Software Product Line," 2011
15th International Software Product Line Conference, Munich,
2011, pp. 223-231.
[44] O. Shmueli and B. Ronen, “Excessive software development:
Practices and penalties,” International Journal of Project
Management, vol. 35, no. 1, pp. 13–27, 2017. [45] M. M.
D. Carvalho, L. A. Patah, and D. D. S. Bido, “Project management
and its effects on project success: Cross-country and cross-
industry comparisons,” International Journal of Project
Management, vol. 33, no. 7, pp. 1509–1522, 2015.
[46] M. Padalkar and S. Gopinath, “Six decades of project
management research: Thematic trends and future
opportunities,” International Journal of Project Management,
vol. 34, no. 7, pp. 1305–1321, 2016.
[47] K. M. Whitney and C. B. Daniels, “The Root Cause of Failure in
Complex IT Projects: Complexity Itself,” Procedia Computer
Science, vol. 20, pp. 325–330, 2013.
[48] M. Kozak-Holland and C. Procter, “Florence Duomo project
(1420–1436): Learning best project management practice from
history,” International Journal of Project Management, vol. 32,
no. 2, pp. 242–255, 2014.
[49] J. Varajão, “Success Management as a PM Knowledge Area –
Work-in-Progress,” Procedia Computer Science, vol. 100, pp.
1095–1102, 2016
[50] T. O. Lehtinen, M. V. Mäntylä, J. Vanhanen, J. Itkonen, and C.
Lassenius, “Perceived causes of software project failures – An
analysis of their relationships,” Information and Software
Technology, vol. 56, no. 6, pp. 623–643, 2014..
[51] P. Sharma and A. L. Sangal, “Investigating the factors which
impact SPI implementation initiatives in software SMEs—A
systematic map and review,” Journal of Software: Evolution and
Process, vol. 31, no. 7, 2019.
[52] H. Al-Abrrow, A. Alnoor, and S. Abbas, “The Effect of
Organizational Resilience and CEO’s Narcissism on Project
Success: Organizational Risk as Mediating
Variable,” Organization Management Journal, vol. 16, no. 1, pp.
1–13, Jun. 2018.
[53] U. U. Moneke and I. I. Echeme, “Causes and Effects of Scope
Creep on Large-Scale Public Sector Construction
Projects,” International Journal of Engineering and Technical
Research (IJETR), vol. 5, no. 2, pp. 165–172, Jun. 2016.
[54] H. Kerzner, Project management: a systems approach to
planning, scheduling, and controlling. Hoboken, NJ: Wiley,
2017.
[55] G. M. G Farok and J. A. Garcia, “Scope creep monitors level of
satisfaction, cost of business and slippery slope relationships
among stakeholders, project manager, sponsor and PMO to
execute project completion report,” Journal of The International
Association of Advanced Technology and Science, vol. 2, no. 2,
pp. 15–23, Feb. 2016.
[56] M. Rene and E. Taylor-Powell "Analyzing qualitative data"
University of Wisconsin-Extension. Cooperative Extension
Madison Wisconsin USA 2003.
[57] B. Hancock, " An Introduction to Qualitative Research , Trent
Focus Group", Nottingham (2002)
[58] U. I. Janjua and J. Jaafar, "Role of academia to make current
practices of software project risk management more effective: An
exploratory study," 2015 International Symposium on
Mathematical Sciences and Computing Research (iSMSC), Ipon,
2015, pp. 274-279.
[59] S.H. Khandkar "Open coding" University of Calgary vol. 23 2009.
[60] V. Greiman, Megaproject: lessons on risk and project
management from the Big Dig. Hoboken, NJ: John Wiley & Sons,
Inc., 2013.
[61] B. A. Carkenord, “Three proven ways business analysts help
prevent scope creep,” Project Management Institute, 2014.
[62] A. A. Nabet, K. M. El-Dash, M. K. ElMohr, and M. A. Mohamed,
“Managing scope creep in construction projects in Egypt.”
[63] R. Govindaraju, A. Bramagara, L. Gondodiwiryo, and T.
Simatupang, “Requirement Volatility, Standardization and
Knowledge Integration in Software Projects: An Empirical
Analysis on Outsourced IS Development Projects,” Journal of
ICT Research and Applications, vol. 9, no. 1, pp. 68–87, 2015.
[64] M. Jørgensen, “A Review of Studies on Expert Estimation of
Software Development Effort,” Software Process Improvement,
pp. 247–293.
[65] O. Hussain, “Direct Cost of Scope Creep in Governmental
Construction Projects in Qatar,” Glob. Journals, vol. 12, no. 14, p.
13, 2012.
[66] M. Ajmal, M. Khan, and H. Al-Yafei, “Exploring factors behind
project scope creep – stakeholders’ perspective,” International
Journal of Managing Projects in Business, vol. ahead-of-print, no.
ahead-of-print, 2019.
[67] C. W. C. Jr., K. Castelle, and J. J. Shauger, “Interpreting barriers
to success in software development and deployment using
systems theory,” International Journal of System of Systems
Engineering, vol. 7, no. 1/2/3, p. 143, 2016.
[68] M. Zaffar, S. Khan, and W. Ahmad, “Causes of Time and Cost
Overrun: A Case Study of Health Sector Projects in Peshawar,
KP,” International Journal of Experiential Learning & Case
Studies, vol. 4, no. 2, pp. 278–296, Dec. 2019.
[69] E. W. Larson, Project management: the managerial process with
MS Project. New York, NY: McGraw-Hill, 2013.
[70] F. Shirazi, H. Kazemipoor, and R. Tavakkoli-Moghaddam,

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.3007098, IEEE Access
VOLUME XX, 2017
“Fuzzy decision analysis for project scope change
management,” Decision Science Letters, pp. 395–406, 2017.
[71] J. Ward and A. Aurum, "Knowledge management in software
engineering - describing the process," 2004 Australian Software
Engineering Conference. Proceedings., Melbourne, Victoria,
Australia, 2004, pp. 137-146
[72] W. Turk, “Scope creep horror,” Defense AT&L, vol. 39, no. 2, pp.
53–55, 2010.
[73] B. Jenner, U. Flick, E. von Kardoff, and I. Steinke, A companion
to qualitative research. Sage, 2004.
[74] B. Komal, U. I. Janjua and T. M. Madni, "Identification of scope
creep factors and their impact on software project success," 2019
International Conference on Computer and Information Sciences
(ICCIS), Sakaka, Saudi Arabia, 2019, pp. 1-5.
[75] S. Pühl and R. Fahney, "How to assign cost to “avoidable
requirements creep”: A step towards the waterfall's
agilization," 2011 IEEE 19th International Requirements
Engineering Conference, Trento, 2011, pp. 307-312.
[76] R. Akbar, “Performance measurement and accountability in
Indonesian local government.” Curtin University, 2011.
[77] D. Barclay, C. Higgins, and R. Thompson, The partial least
squares (PLS) approach to casual modeling: personal computer
adoption ans use as an Illustration. 1995.
[78] D. Pal, S. Funilkul, and V. Vanijja, “Analyzing the Elderly Users
’ Adoption of Smart-Home Services,” IEEE Access, vol. 6, pp.
51238–51252, 2018.
[79] Shaul, L. and Tauber, D, "Hierarchical examination of success
factors across erp life cycle," 2010 79th Mediterranean
Conference on Information Systems (MCIS), pp.1-27.
[80] P. Frey, F. Lindner, A. Muller and A. Wald, "Project Knowledge
Management Organizational Design and Success Factors - An
Empirical Study in Germany," 2009 42nd Hawaii International
Conference on System Sciences, Big Island, HI, 2009, pp. 1-14.
[81] J. F. Hair, W. C. Black, B. J. Babin, and R. E.
Anderson, Multivariate Data Analysis: Pearson New
International Edition. 2013.
[82] A. A. Khan, J. Keung, M. Niazi, S. Hussain, and A. Ahmad,
“Systematic literature review and empirical investigation of
barriers to process improvement in global software development:
Client–vendor perspective,” Information and Software
Technology, vol. 87, pp. 180–205, 2017.
[83] J. C. Hayton, D. G. Allen, and V. Scarpello, “Factor retention
decisions in exploratory factor analysis: A tutorial on parallel
analysis,” Organizational research methods, vol. 7, no. 2, pp.
191–205, 2004.
[84] F. A. Rasheed and M. F. Abadi, “Impact of service quality, trust
and perceived value on customer loyalty in Malaysia services
industries,” Procedia - Social and Behavioral Sciences, vol. 164,
pp. 298–304, 2014.
[85] J. F. Hair, M. Sarstedt, C. M. Ringle, and J. A. Mena, “An
assessment of the use of partial least squares structural equation
modeling in marketing research,”Journal of the academy of
marketing science, vol. 40, no. 3, pp. 414–433, 2012.
[86] M. Sholihin and D. Ratmono, “Analisis SEM-PLS Dengan
WarpPLS 3.0,” Yogyakarta: CV. Andi Offset, 2013.
[87] M. N. Shafique and M. M. Khurshid, “The Role of Wearable
Technologies in Supply Chain Collaboration : A Case of
Pharmaceutical Industry,” IEEE Access, vol. 7, pp. 49014–49026,
2019.
[88] P. B. Lowry and J. Gaskin, "Partial Least Squares (PLS) Structural
Equation Modeling (SEM) for Building and Testing Behavioral
Causal Theory: When to Choose It and How to Use It," in IEEE
Transactions on Professional Communication, vol. 57, no. 2, pp.
123-146, June 2014.
[89] Frost, J. (2019), “How to interpret R-squared in regression
analysis”, Statistics by Jim, Making Statistics Intuitive, available
at: http://statisticsbyjim.com/regression/interpret-r-squared-
regression/
[90] Rubinstein, D. (2007), “Standish group report: there's less
development chaos today”, Software Development Times,
availableat: http://www.sdtimes.com/printArticle/story‐
20070301‐01.html (accessed January 20, 2020).
[91] T. S. Group, “The CHAOS Report,” Standish Group
International, January 1994, 2003.
[92] N. Roberts and J. B. Thatcher, “Conceptualizing and Testing
Formative Constructs : Tutorial and Annotated Example,” ACM
SIGMIS Database, vol. 40, no. 3, 2009.
[93] Neetu Kumari S. and A. S. Pillai, "A study on project scope as a
requirements elicitation issue," 2014 International Conference on
Computing for Sustainable Global Development (INDIACom),
New Delhi, 2014, pp. 510-514.