An Empirical Investigation of Factors Causing Scope Creep in Agile Global Software Development Context: A Conceptual Model for Project Managers

Scope creep is considered as one of the crucial reasons for the failure of traditional software development projects. The ability to manage and control the change elements on a project, particularly the project scope, is a key to project success. The notion of agile process was introduced to tackle the scope change-related challenges such as scope creep. By adopting an agile-footed process, the development organizations can react to the consistent market changes and client requests. However, continuous change accommodation may negatively impact on the success of the targeted project since the project manager mainly focuses on controlling scope change rather than analyzing its impact on the cost and quality. The agile-process advocates have accepted that this situation could happen even following agile methodology, which prompts on compromising the quality, postponed the plans, increases the cost, plan to modify, and diminished the consumer loyalty. Additionally, the scope-related challenge significantly increases, especially when managing scope creep in Global Software Development (GSD) context. Thus, there is a need to focus on scope creep factors in the context of AGSD. Motivated by this, current work aims at identifying the factors causing scope creep in the context of AGSD. To achieve the targeted objectives, we reported the current state-of-the-art related to existing scope creep models in AGSD context. We performed a systematic literature review and an empirical study to address the formulated research questions. The current study also identifies the additional challenges of scope creep from the industrial perspective. Based on the obtained results, the current work proposes a conceptual model for scope creep to assist the agile practitioners to effectively handle the scope creep, which ultimately increases the project success and forecasts change control effect on a software project. Moreover, the proposed conceptual model’s effectiveness is validated through expert judgment and a case study. The obtained promising results ensure the additional aspects of AGSD; hence, the project manager could overcome the project’s overall risk by implementing the proposed model.


I. INTRODUCTION
Agile Global Software Development (AGSD) refers to the globalization of software development activities based on agile practices [1]. Despite its vital importance, very few studies are published in this research context. The associate editor coordinating the review of this manuscript and approving it for publication was Mahmoud Elish .
Many software companies recently globalized their development activities through an emerging development mode, particularly GSD [2]. In GSD, the development is carried out under various circumstances like geographic, temporal, and cultural differences. On the other hand, it serves many benefits like improved time to market, access to the skilled labor pool, and low cost of developers. In the GSD process, the project scope is defined, and the resources are allocated, but there is still a considerable ratio of project failures in global software development. AGSD is also considered very fast, iterative, and handled the projects within a time frame. But still, there are many scope creep factors highlighted in the different studies [3]. The scope creep is also very common, and besides the overcome solution, there is still a lack of implementation of solutions. The main focus of this research is to highlight new issues and identifying the primary factors that may cause the creep at any stage of the project scope. It is also considered that, once the creep factors are identified, what are the main reasons which are still needed to take into consideration by project managers [4].
Scope creep is considered the main problem in software development [5]. There are three main pillars in every project: resources, technical aspects, and consumer aspects. Scope creep has various types of parameters, but these are categorized into these three areas. Some of the researchers considered these pillars as a triangle of the whole project because these multi-dimensional aspects provide coverage to the overall project. Hence, scope creep factors would be increased in case of an issue in any area [6].
Through the conducted systematic review, scope creep factors are identified from the literature. To the best of our knowledge, the current state-of-the-art lacks categorizing and providing a control mechanism of scope creep in agile GSD [7].
Motivated by this, current research aims to conduct a Systematic Literature Review (SLR) to identify the scope creep factors in AGSD, which are mainly considered primary factors, and then identify the creep factors' categorization. It is also the objective of the study to find the success factors to overcome the creep factors. In the conducted literature review, quality is the primary consideration because it reduces the overall biasness of the drawn results. By considering the quality, the conducted systematic literature review adheres to the principles of transparency, accountability, and audibility.
Based on the targeted research objective, the following research questions are devised: RQ1: What are the factors which cause scope creep in software development?

RQ1.1:
What are the critical factors which cause scope creep in AGSD? RQ1.2: What are the additional AGSD factors, according to practitioners, that may affect scope creep? RQ1.3: How can the identified factors be categorized?

RQ2
: What are the current state-of-the-art models managing scope creep?
As the literature lacks in categorizing and identifying the scope creep factors in the AGSD context, the research identifies and validates factors from AGSD scrum masters. A detailed categorization of factors is provided. We have covered tools/models for managing scope in global software development and studied controlling mechanisms to control Project, Product, People). c) Analyzing the existing models, tools, and techniques for scope change management in the AGSD context. d) Assessing the existing scope creep controlling mechanisms. e) Devising a conceptual model to control scope creep in the AGSD context grounded on the current state-of-theart solutions. The remaining part of this paper is organized as follows: Section II provides a detailed overview of research motivation for current research work. Section III described the related work, Section IV presents the adopted research methodology, while Section V presents the results concerning the formulated research questions. The discussion is provided in Section VI. Section VII presents the proposed conceptual model, while Section VIII presents the validation of the proposed conceptual model. Section VIII outlines the threats to validity. Finally, the conclusion and future work is provided in Section IX.

II. RESEARCH MOTIVATION
A substantial commitment to the ineffective project is the lack of characterizing or comprehending the project and project scope towards the undertaking. A properly characterized and managed scope prompts transmit a quality product in agreed cost and intimate determined time schedules. According to Chaos Report from Standish Group, 51% of IT ventures are ''tested'' -genuinely late, over the financial plan, and anticipated deficient highlights [6]. Figure 1 presents the statistics regarding project failures due to scope creep.
As indicated by Standish Chairman Jim Johnson, ''the primary purpose behind the high level of ''tested'' ventures VOLUME 9, 2021 is extension creep [6].'' Contrasted with the consequences of a 1997 Chaos report by the Standish Group that showed 52.7% [8] of ventures will encounter cost invades, IT ventures' achievement pace has not generally improved a lot. Of the central point that makes a ''tested'' project, changing prerequisites and specifications (for example, scope creep) was recorded 3 rd with 12% [9] of all tasks encountering such issues to the partners. The complexity of managing the scope creep is stressed and appraises the movement of monitoring and overseeing fluctuating requirements, which consume 25% of assets in large-scale scope projects, as shown in Figure 1. To the best of our knowledge, this work is different from the current state-of-the-art in the following ways: a) Literature focuses on traditional software development scope creep reasons, but there is no identification and categorization in the context of AGSD Scope Creep Factors. b) There is no mapping of factors in the literature following any software engineering standards. Thus, this research focuses on providing a detailed taxonomy and mapping the parameters based on 4'Ps. c) The conceptual model to control scope creep will help project managers effectively evaluate the impact of change on the cost, time, quality, stakeholder involvement, and design rework since no conceptual model is introduced to control the scope creep in the AGSD context the existing literature. d) The importance of people-related factors is highlighted in the conceptual model compared to existing literature; many studies have quantified the human-related factors, which is subjective. Figure 2 refers to the practices of agile in the GSD context. The combination of agile and GSD is focused on the challenges of GSD, including communication, coordination, team cohesion, geographic location, and time zones difference. These are strengths of agile (extensive collaboration, selforganize and collocated team, and frequent change accommodation), and the combination of agile and GSD can lead to short time to market, managing development cost, and managing requirements change [10].

III. RELATED WORK
Jalali et al. [10] conducted an SLR on global software engineering practices followed in the Agile process. The researchers focused on the overall global software engineering parameters for Agile-based software development. They linked them into specific areas and steps to categorize the GSE parameters concerning the process. Baig and Kureshi [3] identified the scope creep factors, development projects and determine the expected loss due to the scope creep factors. The authors categorized the scope creep factors according to their seriousness and importance. Some factors are considered negligible, fractional, moderate, significant, and drastic. So, as a project manager, one should It is essential to work on scope creep factors as early as possible. If the creep factors are highlighted in the design phase, such factors' negative impact can be reduced [11]. In the design phase of development, requirements are already cleared for stakeholders. Hence, it is an essential phase to handle all of the scope creep factors. This is because the client has delivered the requirements and the vendors, or the development team agreed upon the requirements. They have started delivering the design deliverables. So, if the design is approved without the critical creep factors, then there are very good chances of successful projects. So, the design phase is very important to tackle scope creep.
It can also be observed from the study [4] that every characteristic of a software project has its creep factor. Creep occurs every time requirements are increased during the development process, over budgeting, or adjusting the project's cost during the development process. The original project management scope and its parameters that can affect the project should also be identified to avoid creep.
It can also be observed from another study conducted by Moneke et al. [13]. The authors focused on the causes of scope creep factors and their effect on the whole development process. One of the main reported causes is lack of defined procedure by the project managers, lack of formal communication plan, unavailability of formal risk analysis planning, inability to manage the stakeholders, incompetent project manager, lack of knowledge, and poor project understanding.
Similarly, in another study [5], some other causes of project failures are highlighted, including the scope creep factors. The authors have collected the data from the participatory study process and applied the grounded theory to the research to find the results. The research methodology also includes the case study, in which a web-based project is developed, and the researcher tried to identify the scope creep factors. They adopted four main stages: problematization, intersegment, enrollment, and mobilization change [10]. Notice that the literature focusing separately on agile, and GSD is a shred of evidence that the context of AGSD is still not considered thoroughly. Therefore, the current study aims to target the scope creep factors in the AGSD context.

IV. RESEARCH METHODOLOGY
To achieve the targeted objectives, we have conducted a Systematic Literature Review (SLR) to identify the factors that cause scope creep in the AGSD context. In the performed SLR, we have selected 81 studies and extracted the relevant data. Following the SLR, we have collected the data from 305 project managers through a questionnaire and then included responses of project managers working in agile and global software development, which were 154 in numbers. The detail of the conducted SLR and survey are given in the following subsections.
An SLR is used to recognize, understand, and translate the latest research's entirely available side shape for research questions, topics, or interests. The primary motive is to grow knowledge and make it clean to get oneself acquainted with the research which has already been done [14]. Figure 4 shows three main phases of the conducted SLR. The phases are: (i) planning the review, (ii) conducting the review, and (iii) reporting the review. For conducting the SLR, we have followed the standard guidelines suggested by Kitchenham [14]. The phases of SLR are discussed in detail in the subsequent sections.

A. PLANNING THE REVIEW
A strategy was planned to start a literature review including devising the research questions, selection of search repositories, formulating the search strings, developing the inclusion and exclusion criteria, selecting the primary studies based on inclusion and exclusion criteria, and devising the quality assessment criteria for study selection to ensure that only authentic known quality work is retained.

RQ2
: What are the current state-of-the-art models useful for managing the scope creep in the AGSD context?
After formulating the research questions, we have selected the data repositories for the extraction of the potential studies. The data repositories were selected based on the frequency of the publications of relevant work in the particular database and the selected keywords.

2) SEARCH REPOSITORIES
We selected various databases to identify the potentials studies published in peer-reviewed journals, conference proceedings, and so on. These databases were chosen on preceding research experience, personal knowledge, preferences, and recommendations provided by Arif et al. [50]. In total, five databases were selected, including Science Direct, IEEE, ACM, Springer, and Google Scholar. We observed that majority of the potential studies were retrieved from Science Direct, IEEE, ACM, and Springer. While few research papers were retrieved using Google Scholar.

3) SEARCH STRING
Once research questions were defined, the next step was to develop a search string based on the selected keywords. The keywords and their alternatives were chosen based on the available literature on scope creep in the AGSD context. We categorized the search terms into four groups, (i) agile, (ii) GSD, (iii) scope creep, and (iv) model or framework. Moreover, the search strings were tailored according to the selected databases due to the different searching mechanisms of the databases.

4) INCLUSION CRITERIA
It is crucial to have a pre-characterized protocol to limit the probability of researcher inclination [9]. An audit protocol is included in this study for a specific strategy to search, determine criteria, and incorporate. Acceptance and criterion have been applied to the data which is extracted from the query. Following inclusion criteria is followed to select the potential studies [14].
IC1: The study published between the years 2010 to 2020 was selected. This is because technology is rapidly changing; thus, it is essential to analyze the latest approaches to recover traceability links among the artifacts.
IC2: The study should explicitly refer to software scope management, and scope creep in the AGSD context. IC3: The studies that discuss the challenges or factors causing scope creep in the AGSD context. IC4: The study that contains keywords that may match with those defined in the search string

5) EXCLUSION CRITERIA
It is essential to define the exclusion criteria to exclude the irrelevant studies. As previously mentioned, the studies published from 2010 to 2020 are included, and the rest were excluded. Following are exclusion criteria applied in this work [14]: EC1: The study whose full content or data is not available is excluded.
EC2: The study written in a language other than the English language.
EC3: The study does not focus on software scope management.
EC4: The studies that are published before 2010.   ing quality assessment criteria. The complete list of selected primary studies, along with the references, is presented in appendix A (selected primary studies).

7) QUALITY ASSESSMENT FOR STUDY SELECTION
Quality assessment is a mandatory part of an SLR. As previously mentioned, we have prepared a search string for each repository to obtain the potential studies. To ensure the study's quality, we have focused on major known authentic repositories, only. Secondly, the selection criteria itself is a quality measure consisting of a checklist shown in Table 2.
After the utilization of inclusion and exclusion standards, 66 studies were chosen. The distribution year of the chose investigations were from 2010 to 2020. For assessing the nature of selected articles, a quality assessment checklist was characterized, as shown in Table 2. Quality Assessment Criteria (QAC) permits determined the most pertinent articles inside the ideal examination space. Four checklist questions were planned from the writing and as per the SLR scope. The scoring scale depended on division Yes (Y)/No (N)/Partial (P). A score of 1 is for certifiable answers, 0 for negative ones, and a score of 0.5 with the chance of halfway participation in the inquiry. A score is less than one was considered in an exclusion criterion.

B. CONDUCTING THE REVIEW
This phase of the SLR could be referred to as the implementation stage. As mentioned earlier, we have created  and applied the search string in different research repositories. We have selected the research articles, so here we are investigating the quality of collected papers and detailed parameters as well, which are highlighted. For this, the first step is the primary selection of research articles.

1) PRIMARY STUDY SELECTION
In this phase, we have compiled several research papers found through different research repositories and transform them through the cleansing and analysis process to find the relevant papers. As previously mentioned, we have explored several authentic research repositories, used the specific search string, and found many relevant research papers. Figure 5 represents the tollgate approach for study selection.
The exclusion of irrelevant studies is important as it challenges the overall quality of the conducted SLR. For this purpose, we have reduced the number of research articles based on the selection criteria based on title, abstract, and introduction. Table 3 represents the selected articles using the tollgate approach [75], retrieved from the considered data repositories.

2) DATA EXTRACTION
To answer the formulated research questions, we have extracted articles from the research repositories. Then, the selected studies were examined separately in terms of the title, headings, introduction, research methodologies, figures, tables, results, and any other significant content or parameter relevant to our research work.

3) DATA SYNTHESIS
Data synthesis focused on filtering the potential articles to ensure the research's quality and effectively answer the devised research questions. For this purpose, we have highlighted articles selected in previous steps for review regarding their methodology. Secondly, we also considered categorizing or sorting publications year-wise to get a detailed analysis of improvements and enhancements encountered annually.

C. REPORTING THE REVIEW
After collecting and reviewing research papers, we have analyzed each paper individually. Following, we have discussed the research and study types of each selected paper.

1) TEMPORAL DISTRIBUTION
Temporal distribution refers to each selected article's research or study type and the year of the article's publication. This phase helps us to identify the trend through the mapping of different types of studies following the selected years. Figure 6 represents the temporal distribution of the selected primary studies.
Once the pre-requisite activities of SLR are performed, we have then analyzed the obtained information and answered the formulated research question. The subsequent section contains the details on the results and analysis.

V. RESULTS AND ANALYSIS
This section provides results and analysis regarding each of the devised research questions.
RQ1. What are the factors which cause scope creep in software development? To answer RQ1, the scope creep factors were extracted from the literature. The influence of the identified factors is multi-dimensional; the identified factors may affect positively or negatively. Due to the dispersed nature of GSD, these factors are often neglected, resulting in the scope creep of the project. A total of 66 out of 81 studies targeted the factors, whereas some studies specifically targeted the mechanisms or models. The existing literature discussed scope creep factors but lacked empirical validation. To overcome the shortcomings of the existing studies, we have validated the identified scope creep factors from practitioners (project managers) to legitimacy the obtained results. The initial list of the scope creep factors identified through literature is listed in Table 4. The labels include the factor id, factor name, reference factor, and percentage of the occurrence ( Table 4).
The description of the extracted scope creep factors is provided below: SC1: BUDGET CONSTRAINT Budget is a very common and important factor of project management creep. It is highlighted in various studies are given in [6], [16], [17]. Sometimes, when the project management team doesn't properly investigate the budget, maybe when it goes beyond the budget, creep occurs in all the activities. Moreover, it may cause wrong deliverables, low quality, or often the failure of the project. SC2: COMMUNICATION Communication between teams, stakeholders, artifacts, and documents is always an active topic of discussion in research and development activities [18]. This factor is highlighted in most of the research articles which we found in the conducted SLR [19]- [21]. Secondly, there is still a need to address this issue, especially in global software development, where teams work in multiple locations and have different environments and cultures.
SC3: CONSTANTLY CHANGING REQUIREMENTS: Constant changes in requirements are highlighted as a major factor of project creep. Stakeholders must be confident about the discussion and understanding of requirements at the early stages [22]. Constantly changing requirements from the client side may put more pressure on the development team and project managers. This situation can cause a major creep in project management [23].
SC4: EGO The project manager has inflated pride, ego, or confidence in himself and his team. The project manager thinks that they can accomplish anything. The team might make the change, but that's not the required task to do. This ego may come up as a creep at the end [22], [23].
SC5: LACK OF FEEDBACK Agile development gains popularity in that it ensures the continuity of feedback consideration [17]. The creep occurs when project managers avoid taking feedback from the clientside or end-users.
SC6: LACK OF KNOWLEDGE Lack of knowledge is also highlighted in many articles [24], [25]. Furthermore, this can cause creep at both ends (business side as well as development side). The development side could be the lack of knowledge of tools and technologies. The lack of knowledge refers to the lack of business domain knowledge and explanation on the business side. This is also a creep factor in project management.
SC7: NEED TO ENCOUNTER UNCERTAINTY Another factor of creep is uncertainty, which is needed to encounter at very early stages. Project managers should be VOLUME 9, 2021 able to cater to possible uncertainties at the start that could occur in terms of the development team or managerial or costrelated issues [26].
SC9: ORGANIZATIONAL CAPABILITIES The organization should be capable of running complete project activities smoothly. The creep occurs when project manager overestimates their organization's capabilities in front of clients just to obtain projects. Once the project goes to the middle level, both sides of stakeholders know the realities of the organization's capabilities to deal with the project, and it may cause a creep [27].
SC10: POOR SCOPE MANAGEMENT Project scope management is also a key factor that should be considered in the project's early stages [6]. The project manager should recognize the Scope in terms of deliverables and the project's future [28]. But if the project manager is poor in analyzing the project's Scope properly, it will cause a creep.
SC11: PROJECT COMPLEXITY The complexity of the project is another parameter that is often hidden at the start of the project. Software development organizations may not have got the complete details of the requirements and take the project, but often it creates complexities in the mid of the project. So, this may cause late delivery or, most often, failure of the project [17], [29], [30].
SC12: PROJECT SIZE Agile development refers to fast development and fast delivery. For this, the development and business team should also be aligned to the Agile manifesto [6], [31]. If the project size is big, there could be an issue. As highlighted in various studies, that at the start, project managers don't realize the size of the project, which may cause creep at the later stage.
SC13: QUALITY ISSUES Quality is also a creep factor that comes from the business side. But it is not a creep until it is demanded at a very late stage or the project's delivery. The development team should deliver a quality product, but quality requirements should also be finalized at the start of the project on the business side [6], [32].
SC14: STAKEHOLDER INVOLVEMENT The project's success is the team effort, and every stakeholder should be involved in all activities of the project. If any stakeholder, either from the business side or the development side, reduces his/her involvement in activities, it may cause creep in project management. Secondly, in Agile development, continuous feedback is involved at every stage, so every stakeholder should actively make the project successful [17], [33].
SC15: STANDARD AND POLICIES Organizations should follow the standards and policies for software development activities that involve all project management standards and policies. There should be a clear path in Agile methodology to follow all the standards and policies to avoid a creep at any stage [22]. SC16: TIME CONSTRAINT Time constraints are an important creep factor in ensuring project delivery on time. Lack of understanding of the projects' requirements and complexity may result in late delivery of the project [30], [34].
SC17: UNAVAILABILITY OF RESOURCES Unavailability of resources is also an important factor to consider reducing the risk of project creep. The project managers should be responsible for providing resources to the client committed at the planning phase. However, sometimes resources may shift to another side or another company which may cause unavailability of resources.
SC18: UNCLEAR GOALS As a project manager, one should follow a goal-oriented approach to execute the activities of the project. The development teams should also have clear goals based on client requirements. The creep occurs when the team has unclear and unachievable goals provided by the project manager [3], [23]. SC20: UNREALISTIC EXPECTATIONS A project owner may raise sometime unrealistic expectations from the proposed software. And the small IT organizations or the small teams can agree upon the requirements without realizing the requirement is realistic or unrealistic. The same problem is highlighted by Adam et al. [28] that unrealistic expectations can occur multiple changes. It may cause a significant increase in time and budget and ultimately can lead to the project's failure [23]. SC21: INEXPERIENCED STAFF This factor is also important to avoid creep in project management activities. It is quite similar to another factor that is the unavailability of resources or quality team. Project managers should ensure the required experienced staff and know their duties properly.

RQ1.1: What are the AGSD Scope Creep factors according to the industrial perspective?
We have validated the factors (identified from the conducted SLR) in the AGSD industry. For this purpose, a detailed questionnaire was distributed among agile project managers to identify the primary factors that the industry is facing in actual while working in AGSD, represented in Table 5.

A. EMPIRICAL INVESTIGATION OF SCOPE CREEP FACTORS
This section includes details regarding the design and execution of the performed empirical study. Moreover, it contains the analysis performed on the results obtained from the GSD organization. Finally, a comparison has been drawn between literature-based scope creep factors and AGSD Scope Creep factors (industry) to identify critical Scope creep factors in both approaches, as shown in the figure 7.

1) SURVEY DESIGN
The survey method was used to obtain the software cost estimation and barriers practiced in the Pakistan IT industry. About 1450 software project managers were approached having experience of three years or greater than three years  on LinkedIn. The software project managers were first contacted by message on LinkedIn and asked to participate in the research. If the software project managers agreed to participate, the questionnaire was sent to them through a message on LinkedIn. Ultimately, 306 Software Project Managers filled the survey and allowed us to take advantage of their software project estimation experience. We have included the 155 responses of the project manager (working in the AGSD domain) to identify the industry's critical factors.
Moreover, the questionnaire was distributed in more than 24 countries for the legitimacy of the results. A five-point Likert scale was used in the questionnaire with each identified cost driver (strongly agree, agree, neutral, disagree, strongly disagree). The obtained responses were then converted into percentages and further refined with data analysis techniques. The demographics of responses along with the questionnaire and the dataset link are represented in Appendix B.

2) QUESTIONNAIRE DESIGN
The questionnaire consists of three parts and contains closedended questions. Organization Details about the software house and the respondents were obtained from the first part of the survey. The second part of the survey liberated data about the scope creep factors faced in AGSD used in that specific software house. The third portion asked tools that organizations use to manage scope change, and human factors influence scope creep in also evaluated. We have followed the literature scope creep factors, which we have validated from AGSD project managers.

B. EMPIRICALLY VALIDATED SCOPE CREEP FACTORS
In this section, the empirically validated scope creep factors are presented. Moreover, the factors are categorized into three categories: (i) critical factors, (ii) moderate factors, and (iii) low significant factors. The factors were categorized based on the percentages and the standard criteria. The same criteria are followed in similar work [72]. The list of AGSD scope creep factors, along with their percentages, is presented in Table 5.

2) SCOPE CREEP FACTORS HAVING A MODERATE IMPACT
The adopted criteria to categorize the factors with moderate impact is between 45 and 50%. Through the survey, we identified a total of five AGSD factors with a moderate impact on Scope Creep. These factors are [SC6, SC14, and SC5], as shown in Table 7.

3) SCOPE CREEP FACTORS HAVING LOW SIGNIFICANT IMPACT
We adopted the criteria of factors with frequency <45% for the least significant factors to be categorized. According to AGSD experts, these factors have a very low impact on scope creep. The same criteria are followed in a similar study [37]. A total number of five AGSD Scope Creep factors are included in this category. The factors are [SC2, SC10, SC3, SC18, and SC20], as shown in Table 8.

C. COMPARISON OF FACTORS (LITERATURE AND INDUSTRY)
After obtaining the responses through empirical study, we have compared the obtained results of literature and industry. To achieve the targeted objective, we performed the Spearman correlation test to rank the factors of SLR and industry. The comparative percentages of the scope creep factors are shown in Figure 7. The values obtained through the spearman test are discussed in the subsequent section.

1) SPEARMAN CORRELATION TEST
The Spearman correlation test is applied to check the correlation between the traditional (Literature) and AGSD (industry) Scope Creep Factors. The comparison of the ranks obtained from traditional software development and AGSD Scope Creep factors are presented in Table 9. To evaluate the significance of the differences between the results of both approaches, we performed spearman's rank-order correlation test [72]. For the Spearman correlation test, the value of coefficient (Rs) closer to 1 represents the positive correlation. Rs' resulting values closer to −1 indicate a negative correlation, and Rs values equal to 0 show no correlation. For this study, the Spearman coefficient was −0.21, indicating a weak correlation between the rankings and different critical Scope creep factors. The weak relation represents that the literature does not contain the AGSD scope creep factors. However, it only represents the literature-based scope creep factors. So, in this work, we extracted the literature-based scope creep factors of the software development and validated the extracted factors in the AGSD context, resulting in a weak relationship depicting the variation in the criticality of the AGSD scope creep factors. A factors comparison basis of criticality for both perspectives is shown in Figure 7.

RQ1.2: What are the additional AGSD factors, according to practitioners, that may affect Scope creep?
Along with the validation of the extracted factors, this research also identified the additional challenges associated with scope creep. For this purpose, a section related to the additional scope creep challenges was added to the questionnaire. The project managers provided the additional challenges they have experienced in their professional careers. We have then generalized the factors by checking the relevancy. Following are the nine additional scope creep factors in AGSD, which the agile practitioners have mentioned by their experience.

a: CHANGING MARKET NEEDS
The change in market trends is a continuous process. Organizations continuously improve their technology for better results. So, the development team should also be up to the marked as per the client's requirements.

b: DEVELOPERS ACCEPTING CHANGE REQUESTS
Developers may accept the change request, but not managers. In this case, the legitimacy of the change request is challenged, as the higher management does not review it.

c: MANAGERIAL PRESSURE
Managerial pressure can be seen on both sides (vendors as well as the client). Managers are trying to meet the deadlines, When the project scope is defined, only major changes are scheduled in most cases. However, sometimes minor changes can also cause a delay in the delivery of projects.

e: FIXED COST OF PROJECTS
Most of the projects are signed on a fixed budget. However, due to some technical and managerial issues, project cost grows, which cause the failure of the project.

f: UNWILLINGNESS TO SAY NO TO CLIENT
Some small vendor companies and their employees with a lack of technical and managerial skills are scared to face the client from time to time in case of any issue. If we go to the client to ask the same thing, it will cause an issue.

g: OVEROPTIMISM
Proper management should also highlight the issues and areas which are not achievable in the specific time frame with available resources.

h: LACK OF EXPERIENCE
Selection of the resources should also be based on their skills and experience, not as per the references. Sometimes developers don't have the required skills to work smoothly on the project, which causes failure.

i: LACK OF KNOWLEDGE
If the client doesn't know about the process going on, it will also lead to the project's failure. The client must know about the Scope and proper business knowledge with proper technical details about the ongoing project.

RQ1.3: How can the identified factors be categorized?
To the best of our knowledge, the current state-of-theart lacks defining the standard categories to define the Scope creep factors. For this research, we selected 4P's for categorizing the AGSD Scope Creep factors. This is because the identified factors mapped with all the categories of 4P's [35]. In contrast, one may argue about PMBOK. However, it is more generalized and does not contain specific scope management sub-areas [35]. Mapping AGSD scope creep factors in 4P's could help the Agile project managers better understand how knowledge areas require scope creep factors to achieve better scope management, as shown in Figure 8.
The corresponding factors in the white text represent the factors extracted through the literature (validated by empirical study). In contrast, the factors depicted in the yellow text represent the additional challenges of scope creep, extracted through empirical study (that were not presented in literature).
An expert judgment method was used to map the factors in each defined category of 4P's. We have approached five Agile GSD Experts with strong academic and software development backgrounds. All the identified factors were assigned to 4P's and then validated by each expert. The categories which we have provided in the mutually agreed mapping from each expert which we have approached. We conducted six meetings, each meeting for 1.5 hours, to collect and analyze their suggestions and feedback. Table 10 represents the information about the expert's country, development experience, and academic background. There were three experts from Pakistan while one from Guatemala and one from the United States.

RQ2. What are the current state-of-the-art models useful in managing scope creep in the AGSD context?
To answer RQ2, we have gathered research data from several repositories to ensure literature review quality. For this purpose, we have reviewed different models, frameworks, and approaches presented to highlight the scope of project management creep. The review of the current state-of-theart models managing scope creep in AGSD is presented in Table 11. The labels are the model description, its findings, and the limitations of each model (Table 11).
Notice that this is the customer's responsibility to define project scope, and not defining it causes scope creep [24]. The published work proves that the project's success or failure VOLUME 9, 2021  depends on scope creep in agile methodology [14]. Project scope is a highly effective measure for a project's success or failure. The researchers have found project scope as an additional measure other than cost and time [25]. The author has proposed a conceptual model for managers after taking interviews. The effect of the project scope is studied in various studies, and it is found that scope is as important as any other factor [26]- [29].
Scope creep is to be carried out in an adequately controlled way to overcome failure chances [25]. The causes of Scope creep are identified by different researchers. The study has further discussed the effects of scope creep in the development of project completion. The authors concluded in their study that by controlling these causes, a project could be completed timely and efficiently [30]. The factors that cause scope creep confirm that it negatively impacts the project's success. Unfortunately, there is no such existing model for evaluating the impact on project outcome. This study proposes a model to assess the impact of identified factors that help avoid scope creep. It has been known by different researchers that there is a huge difference between traditional and agile methodologies regarding scope management. A study compared both methodologies and found that agile and traditional methodologies accept scope management as a basic knowledge development [27]. Lack of documentation on agile projects, distributed software development projects, the requirement of industry case studies is high [1]. In contrast, an SLR was performed to analyze how agile methodology has different effects on different aspects of software project management [31].
Scope creep can be avoided if the scope is broken into some points. Prior work has reported that Function Point Analysis (FAP) helps in problem-solving [33]. It is a structured technique that breaks systems into smaller components. They can be better identified and examined. The study found that points have made up enough sizing possible; that make software productivity and software quality improvement. Later, many studies have shown how FAP helps in scope creep. The prior work has shown a transitivity relation between scope creep, function points, and project success [34]. They developed two domains and concluded that there is a high impact of scope creep in realizing project success. Another work proved the real-life impact of scope creep. An investigation was carried out on different projects to see the impact of technology and domain on scope creep [35]. Their research with a case study has proven the influence of real-life examples. In contrast, systematic dynamic modeling was used in one of the published works to check the effectiveness of the Quality Assurance (QA) process [36]. The authors found that the pattern of change order has influenced project progress.
The research has shown a high effect of scope creep in product development. The project's success or failure is identified as multiple factors that consist of time, cost, user involvement in requirement collection, idealistic expectation,  and most importantly, poor management of scope, and so on [37]. An empirical investigation in one of the leading software industries in India having the same maturity level analyzed a high impact of scope creep in project success through customer satisfaction [38]. Later, they investigated several empirical projects and made a 3D visualization of scope creep on the success of the project [39]. A crosssectional, multiple, and mono-method case study design was implemented to explore the managerial perceptions on scope creep [40]. However, the study may have biased results as it is implemented on Norwegian nationals with a small data size only.

VI. DISCUSSION
In this work, we performed a systematic review to find the factors affecting scope creep in the AGSD context. We focus on three research facets: (i) gathering scope creep factors and (ii) collecting methodologies from countering such factors. Regarding RQ1, we concluded that: • Nowadays, many companies are developing projects using an agile approach [3], but they are still counterscope creep [6]. For this reason, we have identified the exhaustive list of scope creep factors in the AGSD context and empirically validated these factors from agile experts working in the GSD context. The current research identified 22 scope creep factors. The identified factors were further categorized based on the criticality.
• Many additional scopes creep challenges are also associated with AGSD that should be considered in scope management. These challenges were identified through practitioners from the AGSD context. The additional challenges include Changing market needs, Developers accepting change requests, Managerial pressure, no scope analysis of minor changes, Fixed cost of the projects, Unwillingness to say no, the client, Over-optimism, Developer's lack of experience, and Client's lack of knowledge. The current state-of-the-art highlighted the scope creep factors through a general literature review [6]. In contrast, we performed a systematic review for extracting the extensive list of scope creep factors. Additionally, we validated the scope creep factors empirically that was the missing factor in the literature.
• We applied spearman's correlation tests to compare the factors, and the results indicate that there is no correlation between literature and the AGSD industry as the Rs value is equal to 0. Thus, we have highlighted critical factors for two perspectives: (i) Scope creep factors in software development and ii) Scope creep factors in AGSD.
• The identified AGSD factors were categorized according to 4P's as they provide low-level details and mapping of identified factors in terms of process, project, product, and people [35]. The mapping and categorization are done through expert judgment as adopted by the relevant work [35]. The literature in agile methodology has observed that its project manager is most responsible for maximum work [22]. As a project manager, one should be familiar with the nature of the project, the client's environment, and their team's capabilities to reduce creep risks. The rest of the team should be aware of tasks not only told by the project manager but also by the client [25]. This will help the agile methodology work effectively.
• The literature also highlighted the importance of design-related factors that any change we are accommodating, minor or significant, will impact the design. If we change the design, we will have to start rework from the initial stage of the software lifecycle [80], and which eventually causes the project to face scope creep and ultimately moves towards failure [45].
Regarding RQ2, we have identified that: • The collected information is based on tools, technologies [86], and the authors who proposed any new framework [79] or methodology [81] to discuss such factors. It is analyzed that a two-sided avoidance mechanism is an ongoing process to reduce the creep factors in the complete project management life cycle [84].
• Additionally, we also summarized the studies in terms of their outcomes or description in main points and their limitations or future work, which they have highlighted to be considered for future researchers and help us develop a model to avoid scope creep in AGSD. The aim of this research question was to analyze the shortcomings of the existing models so they could be improved when applied in the AGSD context.
The summarized results indicate a need to propose a model based on the identified AGSD scope creep factors. Therefore, based on the obtained results of the formulated research questions, we proposed a conceptual model to assist the project manager by incorporating these AGSD scope creep factors. A detailed discussion of the proposed model and its phases are discussed in the subsequent section.

VII. PROPOSED CONCEPTUAL MODEL
Based on the results of conducted SLR and the empirical study, we developed a conceptual model to control scope creep in the AGSD context. Figure 9 presents the main components of the proposed conceptual model. As previously mentioned, we categorized the AGSD Factors according to 4P's. We used these categorizations and analyzed each factor's direct and indirect impact on cost, time, quality, design rework, and stakeholder involvement. The outcome of this phase will be a detailed causal model for each parameter.
Based on the causal model, we can assign complexity to each factor except the human factors as the human traits are subjective, and we cannot quantify these people sections from 4P's. A detailed mathematical model will be developed in phase 3. This model's outcome will be the calculated percentage effect of desired scope change on the cost, time, quality, design rework, and stakeholder involvement. The Agile project manager will have the idea that if he accepts the change, he/she has this percentage effect on the project success parameters, design reworks, and stakeholder involvement. With these statistics' help, the project manager cannot decide the scope change acceptance or rejection strategy accordingly. In the proposed conceptual model, the factors were empirically validated by 154 AGSD project managers. The model considers a detailed list of Scope creeps factors covering all the aspects of scope creep in an AGSD context. Figure 10 represents the detailed conceptual model, including the phases and sub-phases. The associated phases are described in the subsequent sections.

A. PHASE 1: IDENTIFICATION AND VALIDATION
This phase presents the list of empirically evaluated factors affecting scope creep in AGSD and categorizing the identified factors based on 4P's categorization.

1) IDENTIFICATION OF COST DRIVERS
The factors are extracted through SLR and are validated by the AGSD practitioners. The identified factors have a significant impact on scope creep while working in AGSD. The identified factors are visualized previously in Figure 7.

2) CATEGORIZATION OF AGSD SCOPE CREEP FACTORS
The identified 29 scope creep factors that affect scope creep are categorized in this section. The identified factors are categorized using 4P's, People, Product, Project, and Process. The categories with the corresponding factors are depicted in Figure 8. The rationale behind the mapping of the identified factors is listed below: a: PEOPLE-RELATED AGSD FACTORS These factors are based on personal traits, experience, and attributes. A detailed guideline to deal with these factors is highlighted in the conceptual model. As the development type vary, the personal attributes also vary with the change in development type. The factors included in this category are Ego, organizational capabilities, lack of knowledge, stakeholder involvement. Unrealistic expectations, inexperienced staff, lack of feedback, client's lack of knowledge, developer's lack of experience, unwillingness to say no to the client, and over-optimism.
In AGSD, the project manager has inflated pride, ego, or confidence in himself and his team. The project manager thinks that they can accomplish anything. The team might make the change, but that's not the required task to do. This ego may come up as a creep at the end. Stakeholder involvement is crucial in the AGSD project as the project's success is the team effort, and every stakeholder should be involved in all activities of the project. If any stakeholder, either from the business side or from the development side, reduces his/her involvement in activities, it may cause creep in project management. Secondly, in Agile development, continuous feedback is involved at every stage, so every stakeholder should actively make the project successful. A project owner may raise sometime unrealistic expectations from the proposed software. And the small IT organizations or the small teams can agree upon the requirements without realizing the requirement is realistic or unrealistic. The same problem is highlighted by Adam et al. [9] that unrealistic expectations can occur multiple changes. It may cause overtime and over budget and ultimately can cause the project's failure [4].

b: PROCESS-RELATED AGSD FACTORS
Process-related factors represent the scope creep factors that are associated with the development methodologies and processes. Effective processes are key to the productive growth of a software company. Due to GSD development's distributed nature, the operations also vary from those used in in-house development. The factors included in this category are communication, standards, and policies, constantly changing requirements, encounter uncertainty, no formal review process for change management, developers accepting change requests, no scope analysis of minor change requests, and managerial pressure. In GSD, communication between teams, stakeholders, artifacts, and documents is always an active topic of discussion in research and development activities [12]. It is highlighted in most of the research articles that are found in the conducted SLR [13]- [15].

c: PROJECT-RELATED AGSD FACTORS
Project-related factors refer to the factors associated with the overall success of the project. These factors are symmetric and are directly linked with the project. In the context of AGSD, the project-related factors include Project complexity, project size, budget constraint, time constraint, quality issues, unclear goals, un-availability of resources, poor scope management, poor initial requirements, and fixed cost of the project. The complexity of the project is another parameter that is often hidden at the start of the project. The software development organizations may not have got the complete details of the requirements and take the project, but often it creates complexities in the mid of the project. So, this may cause late delivery or, most often, failure of the project [10], [17], [18].

d: PRODUCT-RELATED AGSD FACTOR
Product-related factors refer to the factors that impact overall product development. In the context of AGSD, the product-related factors include Changing market needs and unforeseen risks. The change in market trends is a continuous process. Nowadays, Organizations are continuously trying to improve their technology for better results. So, the development team should also be up to the marked as per the client's requirement, and risk analysis is a key project-related factor and contributes to the project's overall success. Figure 10 represents the detailed conceptual model with main phases and sub-phases.

B. PHASE 2: COMPUTATIONAL PHASE
In this phase, complexity is assigned to each factor concerning each mapped parameter-for example, cost, time, quality, design rework, and stakeholder involvement. A mathematical equation is the output of this phase.
In phase 2, quantification is done based on the Causal Model. Complexity is assigned to each factor except the human factors as the human traits are subjective, and we can't quantify these people section from 4P's. In phase 3, The model's outcome will be the calculated percentage effect of desired scope change on the cost, time, quality, design rework, and stakeholder involvement.

1) QUANTIFICATION THROUGH CAUSAL MODEL
After detailed identification and categorization of AGSD scope creep factors using 4P's that covers every aspect of a project, a systematic mapping of factors to each parameter on cost, time, quality, design rework, and stakeholder involvement is represented as an output of phase1 which covers the direct and indirect impact of factors on each parameter. The causal model considers a detailed list of scope creep factors covering all the aspects of scope creep in an AGSD context. It can be seen how different factors can cause scope creep even in Agile methodology, which repeatedly takes every stakeholder in contact in every step.

C. PHASE 3: MATHEMATICAL MODEL
In this phase, the percentage impact of change on the cost, time, quality, design rework, and stakeholder involvement are calculated. The model's outcome is the calculated percentage effect of desired scope change on the cost, time, quality, design rework, and stakeholder involvement. The Agile project manager will have the idea that if he accepts the change, he/she has this percentage effect on the project success parameters, design reworks, and stakeholder involvement. With these statistics' help, the project manager can't decide the scope change acceptance or rejection strategy accordingly. In our conceptual model, the factors were empirically validated by AGSD project managers. The model considers a detailed list of scope creeps factors covering all the aspects of scope creep in an AGSD context.

VIII. VALIDATION OF PROPOSED CONCEPTUAL MODEL
In this section, the validation of the proposed conceptual model is presented. We adopted two modes of validation: (i) expert opinion and (ii) the case study. Firstly, the industrial experts reviewed the proposed model, and the improvement was made; then, a case study is performed to obtain the initial results. A detailed discussion on the validation of the proposed conceptual model is presented in subsequent sections.

1) INITIAL VALIDATION
For validating the proposed conceptual model before sending it to experts, we performed initial validity. For this purpose, version 1 of the proposed conceptual model was reviewed by academic experts Dr. Saif Ur Rehman Khan and Dr. Inayat ur Rehman, currently employed as Assistant Professors at COMSATS University Islamabad (CUI). The initial validity of the model is checked through different parameters such as the readability of the model, the contribution of the model, logical and technical aspects. Once the proposed model was initially validated, we followed the expert's validation process for further improvements. The adopted process of expert validation is shown in Figure 11.

2) EXPERT VALIDATION
We have adopted an expert validation process to validate the proposed conceptual model. In expert validation, the industry experts were selected to validate and review the model; then, the experts decide to either reject, accept, or refine it. The overall process of expert validation is depicted in Figure 11. Moreover, we defined an inclusion criterion for selecting the appropriate experts in this context. The criteria for the selection of experts are listed as follows:

The expert must be currently employed as a'' Project
Manager.'' 2. The expert must have at least five years of experience.
As a result, eight experts meet the defined inclusion criteria. We have attained an expert's response through an online questionnaire designed through google forms. Within the questionnaire, the following aspects were covered related to design, logical relations, labeling, and identify scope creep factors. Table 12 represents the validation criteria and the corresponding questions that were asked from the experts through a questionnaire.
The results produced positive responses from experts, showing that the research instrument measures what it aims to evaluate. The overall visual representation of the expert responses and the designed questionnaire is presented in Appendix C1 (Expert's Responses). However, the summarized expert's responses are presented in Appendix C2. Furthermore, the proposed approach is demonstrated through a case study of an ongoing software house project. VOLUME 9, 2021

3) CASE STUDY
In addition to the expert's validation, we also validated the proposed conceptual causal model of AGSD scope creep categorization with 4P's and their mapping with factors. The proposed model offers a list of factors that are responsible for scope creep in software projects. These factors were then extended by implementing some ongoing five projects in a multinational software company based in Islamabad experts. We have used descriptive research design: • Target Population: The population of this study was 109 employees of five ongoing projects using Agile methodology.
• Sample size: The sample size of the study was 87 respondents selected for the total population.
• Data Collection Tools: Data collection instrument was an interview. Interviews were taken to complete their projects from industry experts working on projects using agile methodologies after implementing the proposed model.
For the case study, respondents revealed the ways through which the cost of the project is increased affect project success is lack of collaboration between the project manager, stakeholders, and team members (23%). In comparison, 21% of respondents said it makes it difficult for the project to attain objectives if time is not properly prioritized, and 29% of respondents said lack of quality of work leads to lack of beneficiary support. 12% of respondents said lack of design rework affects project implementation, and 15% of respondents said failure to involve stakeholders leads to project delays. This result led researchers to the understanding that the proposed model is validated to be helpful if implemented for scope creeping that affects the success of efficient project completion.

IX. THREATS TO VALIDITY
A possible threat to this research is that the selected studies have not targeted both agile and global software development in one context. We have gathered factors from different software development approaches. Not specifically traditional or agile because literature lacks agile or GSD-specific Scope creep factors. This threat is mitigated by validating factors for agile practitioners working in global software development to have validated. Scope creep factors that agile practitioners face in real-time development summarize the critical factors that the industry is facing in AGSD.
There is a possible threat related to the extraction and the aggregation problems that may occur when we have a high number of primary studies. However, to effectively tackle this threat, we have followed the guidelines suggested by Kitchenham et al. [13], where one researcher extracted the data, and another researcher checked the extracted data. Another possible internal threat is that the identified primary studies might not have reported the reasons for the occurrence of the scope creep factors in the AGSD context. This is due to the fact that the origin of the scope creep factors in the AGSD context is not formally identified in the literature. The AGSD scope creep factors were evaluated to mitigate this threat based on their resemblances with the traditional scope creep factors and the expert's assistance.
Moreover, regarding the proposed conceptual model, its efficiency might be challenged while implementing in realworld scenarios. However, to deal with this threat, we have performed a case study to test the effectiveness of the proposed conceptual model. Furthermore, the other performance measures would be evaluated while implementing it through a tool that we intend to target in the future.

X. RESEARCH IMPLICATIONS
This section provides the theoretical and practical implications of current research for future researchers and project managers as follows: • The extensive review of current state-of-the-art could help researchers understand the process of scope creep management in the context of AGSD from various perspectives.
• The proposed conceptual model could be helpful to be served as a guideline for presenting a new scope creep model in the AGSD context as it contains all the primary phases for presenting a new model.
• The identified scope creep factors could be used to better estimate the overhead of the GSD projects by analyzing the impact of change caused by critical scope creep factors.
• The mathematical model of scope creep could be helpful for project managers in identifying the impact of change generated in terms of time, cost or quality.
• If a tool is developed based on the proposed conceptual model, it will help in ensuring the key scope creep features from all stakeholders' perspectives.
• Integrating the proposed conceptual model with the agile scaling frameworks, i.e. SAFe, would support the workflow patterns for implementing the agile practices at an enterprise level. Moreover, it would further improve the company's agility through efficient decision-making     across the company's boundaries considering the critical scope creep factors.

XI. CONCLUSION AND FUTURE WORK
AGSD refers to the globalization of software development activities based on agile practices. Many companies are facing scope creep in projects while working in AGSD due to its market demands. Despite its vital importance, very few studies are published in this context. This motivated us to study scope creep in detail, the factors, models, tools, and existing controlling mechanisms to devise a conceptual model to control scope creep in AGSD projects. To attain the described research goals, we performed an SLR and an investigative study (questionnaire-based survey) to identify factors that impact scope creep. In total, 154 AGSD project managers and their categorization are validated through agile experts. A total of 21 Scope Creep factors are identified. There are many solutions provided or highlighted in the research. For the Agile manifesto, proper feedback is one of the key factors, and understanding the requirements is another. If the project managers do not consider such things, it will cause the projects' failure. Secondly, it is also essential to analyze team capabilities. The teams should be often gone through the skills tests to polish their existing skills and gain the new skills according to the upcoming requirements.
Moreover, many organizations are using global software development. The detailed literature analysis shows no specific tool/method and reasons organizations face scope creep, specifically in AGSD. Moreover, the 21 identified factors indicated 11 critical, five moderate, and five low significant AGSD scope creep factors. The literature-based factors that affect Scope creep in traditional software development, which the literature mentions, are different from AGSD factors based on complexity. There is no correlation between AGSD data and Literature data, spearman's correlation test has proved this.
Furthermore, we have also extensively reviewed the existing models to handle scope creep. We believe that the findings of this study could be used to deal with the issues associated with scope creep and scope change issues in AGSD. Based on the obtained results, we presented a conceptual scope model for handling scope creep in AGSD. The presented conceptual model could assist the project managers to effectively evaluate the impact of change on the cost, time, quality, stakeholder involvement, and design rework. This undermines scope creep in software and assists them in the development of effective control and mitigation strategies. Thereby increasing the project success and forecast change control effect on software projects. As for future work, we plan to devise proper tools to support AGSD. For example, there is a need for a tool to monitor the reported factors in the context of AGSD. Notice that the planned tools are separate from any existing project management tool. This is because that project management tool only monitors the deadlines and resources and lacks in specifically focusing on the creep factors. Moreover, the study aims to integrate the proposed model with agile scaling frameworks, i.e. Scaled Agile Framework (SAFe). It is an interactive knowledge base for implementing agile practices at the enterprise level. Furthermore, the scaling frameworks provide guidance that covers a broad scope, including enterprise architecture.

APPENDIX A
See Table 14.

APPENDIX B
See Table 15.

A. QUESTIONNAIRE LINK
The following link is the main questionnaire that we designed to validate the extracted factors from the project managers: https://docs.google.com/forms/d/1gYj8Ax6G_hwLZTM NWTUgIzxG3c8II0Awkrfd_oBNBuM/edit

B. DATASET (PUBLISHED ON MENDELEY)
The following link contain the dataset of the responses of targeted project managers. The dataset is made publicly available by publishing it on Mendeley repository. https://data.mendeley.com/datasets/fjf53hc6tv/1

APPENDIX C
See

ACKNOWLEDGMENT
The authors are grateful to the Software Reliability Engineering Group (SREG) members at COMSATS University Islamabad (CUI) for their continuous support and feedback throughout this research work. Moreover, they appreciate the project managers and the experts who participated in the survey and provided their valuable responses.
INAYAT-UR-REHMAN received the Ph.D. degree in computer science (e-learning) from COMSATS University Islamabad (CUI), Islamabad, Pakistan, in 2017. He has over 18 years of teaching experience and is currently working as an Assistant Professor with the Department of Computer Science, CUI. His research interests in software engineering domain include software testing, software project management, and software reusability. In the e-learning domain, his research interests include computer-assisted core in education, designing learning tools, computer animations for learning, HCI for design in learning tools, cognitive learning, and the use of educational psychology for e-learning applications. He is extensively involved in conducting training for basic computing courses for national and multinational companies.
ADNAN AKHUNZADA (Senior Member, IEEE) is a Professional Member of the ACM with 13 years of research and development (R&D) experience both in ICT industry and academia. He has a proven track record of high impact published research (i.e., U.S. patents, journals, transactions, reputable magazines, book chapters, conferences, and conference proceedings) and commercial products. His experience as an educator and researcher is diverse that includes work as a lecturer, a senior lecturer, a year tutor, an occasional lecturer at other engineering departments, as an Assistant Professor at COMSATS University Islamabad (CUI), a Senior Researcher at RISE SICS Västerås AB, Sweden, as a Research Fellow and the Scientific Lead at DTU Compute, Technical University of Denmark (DTU), as the Course Director of Ethical Hacking at The Knowledge Hub Universities (TKH), Coventry University, U.K., and a visiting professor having mentorship of graduate students, and supervision of academic and R&D projects both at UG and PG levels. He is currently serving as an Associate Professor with the Faculty of Computing and Informatics, Universiti Malaysia Sabah, Malaysia. He has also been involved in international accreditation, such as Accreditation Board for Engineering and Technology (ABET), and curriculum development according to the guidelines of ACM/IEEE. He is a PI of national and a Co-PI of several Swedish and Horizon 2020 EU funded projects. His main research capabilities and interest lies in the field of cyber security, secure future internet, artificial intelligence (i.e., machine learning, deep learning, and reinforcement learning), large scale distributed systems (i.e., edge, fog, cloud, and SDNs), the IoT, Industry 4.0, and the Internet of Everything (IoE). He is also a member of technical programme committee of varied reputable conferences, journals, and editorial boards. VOLUME 9, 2021