Measuring the Impact of Scope Changes on Project Plan Using EVM

Earned Value Management (EVM) measures project performance against a baseline plan. It identifies deviations in budget and schedule, aids project managers in taking earlier corrective actions against cost and schedule overruns. Although the literature highlights the significance of scope by adopting it as a leading indicator to measure project success or failure. However, EVM does not include scope when evaluating the performance of any software project. While considering the importance of scope and its ever-changing nature, it is imperative to measure the effect of changes in scope on the project plan. To analyse such effects, this study aims to enhance the traditional EVM by incorporating scope into it. The main objectives of this paper are: i) to extract the effects of project scope changes, ii) to map extracted effects of project scope changes with Software Project Scope Rating Index (SPSRI) elements, and iii) to quantify the extracted effects and integrate them with EVM. An extensive literature review is conducted to achieve the first objective, which results in the seventeen unique effects; that were used to map with SPSRI elements. To forecast the variations in scope for a given project budget, Monte Carlo simulations were run on the top eight scope elements, whereas, the results were incorporated with EVM to identify the deviations between actual and projected values of scope’s score and cost. Finally, the multivariate regression model was used to evaluate the influence of individual element on the overall estimated cost of the project. The correlation between the independent variables (SPSRI elements) and the dependent variable (overall cost) was calculated along with the valuation of each independent variable on the dependent variable. Moreover, the effects are statistically shown that independent variables have influenced the dependent variable. This technique could assist the project managers to forecast deviations in project scope earlier.


I. INTRODUCTION
Earned Value Management (EVM) is a widely used technique for monitoring and controlling project performance [1], [2]. It has been used in different disciplines and projects to aid project planning, decision-making and project tracking [3]. Performance of any project could be measured using budget and schedule information. It also provides performance and control indexes to help Project Managers (PMs) take early actions against cost and schedule overruns.
The associate editor coordinating the review of this manuscript and approving it for publication was Young Jin Chun .
According to the PMBOK Guide, EVM is a systematic approach to integrate, monitor and compare the trends of triple constraints (scope, time and cost) in a project [4]. A project needs to cope with it by balancing the these three constraints. Although, these constraints are used to measure the success criteria of the project, however, the scope changes of software projects are not included when measuring the progress of software projects. The scope of the project is considered as a leading indicator to evaluate the success of any software project [5], also monitoring and controlling scope is a significant and difficult job in the area of project management. A lot of software project failures are highlighted in the literature; these failures are mostly associated with the scope of the project [6], [7].
To the extent of our knowledge, several problems were reported in the literature while defining and managing project scope, i.e., inadequate input from key stakeholders, partial scope definition, uninterrupted requirements, scope management issues, requirement volatility, incorrect supposition, inadequate system complication, inappropriate estimation and, uncertain goal and perceptions, etc. [6]- [8]. These problems lead to schedule and budget overrun [9], scopecreep [10], de-scoping [11], over-scoping [12], requirement volatility [13], effort misspend [14], potential risks [15], low quality software's and even results in project failures [16]. A significant amount of projects failure was associated with incomplete and inappropriate definition of scope management [17].
The scope of the project is volatile; it changes from the analysis until the maintenance phase of the software development life cycle [18]. Whenever there is a change in software scope it affects project plan, especially budget and schedule [19]. In the existing literature, it is noted that ''EVM methodology considers scope, time and cost indices while measuring the performance and progress of the project''. Current EVM in both theory and practice uses Cost Variance (CV) and Schedule Variance (SV) to assess the project progress using time and cost indices, respectively. This two variance approach has two limitations; EVM does not include the complete definition of the project scope neither it quantifies the effect of changes in scope on the project plan.
Our contribution in this paper can be summarized as follows: • We have studied the scope effects while dealing with monitoring, controlling and forecasting changes in effects on the project plan.
• We have included project scope in quantification, and effect of changes in scope on project plan. • We have forecasted deviations in scope by projecting different percentiles of scope using percentage completion of the project.
• We have implemented multi-linear regression test to identify relation between dependent and independent variables.
• Finally, we have presented the study with statistical proofs that the said elements have a drastic effect on increasing the overall cost of the project. In this paper variations in the scope's score are explained at a given project budget using mathematical modeling of scope elements and its effects. Afterwards, incorporate this information to generate the ''universe'' of the project by means of Monte Carlo simulations and define triads for every project of the simulation. A triad explains the percentage completion of the project concerning the scope of the project and the cost spend on it. This approach provides data and information regarding the variability of the project scope as provided by EVM. The methodology is coherent with EVM, the data and variances from EVM can easily be transformed into graphs, which is the third main objective of this research.
The main advantage of this approach is to combine two methodologies: EVM and SPSRI. Combining these two methodologies we can integrate scope management (SPSRI) with EVM methodology, in other words, we can integrate monitoring and controlling of scope deviations under the same framework. To address the integration of two methodologies, the following research questions are synthesized.
• RQ-1: What are the state-of-the-art effects of changes in scope on the project plan?
• RQ-2: What are the possible effects of changes in scope against each SPSRI element?
• RQ-3: How can the scope deviations be measured? To answer the RQ1 we have reviewed the existing work based on technique and tools for scope definition and how traditional EVM is used to measure the project performance with triple constraints of project measurement. Findings of literature review are discussed in Section II. Section III builds upon the result of scope change effects extracted from the literature review, mapping of these effects with SPSRI elements, in addition validation of this mapping from the software industry. We have performed mathematical modeling to build a method for the quantification of scope and afterwards results were incorporated into EVM. The detail of the proposed methodology is illustrated through a case study to measure the scope deviations. Finally, Section IVprovides the evaluation of simulated results and Section V discussions and conclusions on adapting methodology.

II. BACKGROUND
The background of this paper is composed of two methodologies; the first method is used to measure the progress of the project. Earned Value Management (EVM) which is considered the most commonly used technique to measure the progress of the project into different engineering disciplines like; electrical, electronic, civil, and IT etc. This technique uses different indices, variances and forecasting mechanisms discussed in Subsection II-A. Second method is used to elaborate the state-of-the-art techniques and tools for scope definition. These tools are used for estimation, monitoring, controlling and quantification of scope using scope definition discussed in Subsection II-B.

A. PROJECT PERFORMANCE MEASUREMENT TECHNIQUES
The basic form of Earned Value Management (EVM) can be traced back to the industrial engineering industry in the late 1800s. The term EVM originates from the U.S. Federal Government in their large acquisition program to control schedule and budget. PMI considered EVM, the most widely used method in different disciplines to evaluate the progress of the project [20]. Three key parameters (PV, EV and AC) are used in the literature for the measurement of EVM. These key parameters are described as follows [21], [22]. PV: Planned budget to be spent on a project also known as ''Budgeted Cost for Work Schedule (BCWS)''.
EV: At any given time, portion of the work actually completed known as ''Budgeted Cost for Work Performed (BCWP)''.
AC: Actual amount of money spent for project accomplishment as known as ''Actual Cost of Work Performed (ACWP)''.
EVM depends on ''well-defined baseline plan against which progress of the project is measured in terms of time and cost'' [24]. Baseline includes original project plan and incorporates approved changes into it. Using this baseline plan, PMs and their teams can decide how well the project is meeting time and cost objectives, by entering real data and afterward comparing it with the baseline.
EVM was originally designed for cost management, later it used to forecast scheduling of the project. Literature shows that during run time execution of the project schedule indicator exhibits inappropriate result, however, PM emphasis on cost indicator [21]. Like cost indicator, there is a need to formalize project schedule in some definite mathematical form, as there exists a strong correlation between cost and schedule of the project. In [22], the author introduced an index named as Earned schedule (ES) to address the schedule performance of the project, defined as the date when current EV should have been accomplished. ES considers the information of cost baseline when planned work is equal to the completed work package. Although this aforementioned indicator used for estimation of those actions which were completed, however, it does not consider those activities which came along subsequently in the critical path. Afterwards, it was applied to estimate incomplete activities by defining mathematical form explained in eq ''(1)''.
where, AT refers to actual time. Indices and variations in the project represented graphically as shown in Fig. 1, helps the PMs to follow the progress of the project. The graphic representation of the PV is used as a reference baseline for the cost of the project. These variances represent that the project is in advance with respect to its baseline is under budget and schedule respectively (shown in Fig. 1).
In order to forecast completion dates of the project along with the estimation of future cost of the project ''Estimate at Completion (EAC)'' are used to compared with different forecasting techniques in [22]. Moreover, the probabilistic control curve limits were introduced to forecast progress of the project [23]. Although, these charts uncover the deviations in budget and schedule from the baseline plan, however, these charts were unable to judge the project performance on the deviations. Four useful indices were introduced to forecast the performance of the project including; 1) Cost Variance (CV), 2) Schedule Variance (SV), 3) Cost Performance Index (CPI), and 4) Schedule Performance Index (SPI). SV determines variations in project schedule, whereas, CV determines variations in the project budget. Similarly, SPI determines how well the project team is using its time, while CPI gauges how the project team is utilizing its resources [24]. The positive value of these variances (SV > 0 & CV > 0) and performance indexes (SPI >0 & CPI >0 )shows that the project is under budget and ahead of estimated schedule of the project. Likewise, Negative value shows problematic situation either over budget or delays while monitoring the performance of the project [23], [24]. In order to forecast something out of the planning occurs it is due to the rework in the project. A new indicator used as extended version of ES named as Schedule Adherence to under impact of rework on schedule performance of the project [25]. At each point in the project rework can be calculated using task of performing rework out of sequence tasks as presented in eq ''(2)''.
Here f(r) is the function used to determine the portion requiring rework.
In [26], the researcher emphasized on monitoring and controlling of quality, as it is same as cost and schedule indicator in the project. The author used integration of linear and Taguchi-based method to monitor and control budget, schedule, quality and risk in the project. The positive value of Quality Variance (QV) and Quality Performance Index (QPI) represent that the quality requirements are met. In the same way, negative value of these indices shows the project is out of the acceptable range. In addition, when project is near to completion, SV will approaches to zero and SPI approaches to one. Although at the earlier phase of project construction it follows the planned estimated schedule, however, at the later stages of the project, schedule of the project did not follow planned estimated schedule, therefore, these indices do not provide appropriate information.
Traditional EVM considers the complete planning of the project, divides the project into manageable work package and then associates each work package with cost and duration of the project. As agile methodology works in form of multiple increments, therefore it questioned the utility of EVM for agile projects. Therefore, adoption of traditional EVM into Agile requires identification and estimation of multiple releases in product backlog. AgileEVM concentrates on measuring progress at the release level, rather than at the sprint level or at the product level. To measure the progress with multiple releases, the author identified each release (using sprint) in the project backlog and estimated the performance of the project at the end of each sprint when actual sprint velocity and actual costs are known [27].
In article [28], the author has integrated monitoring and planning techniques (EVA and Gantt chart) by developing a tool named EV-Gantt. Regardless of measuring the performance of the project this tool assists the project and engineering managers in decision making as well as in resource allocation of the project. In other words, this tool can work well at the project as well as in the portfolio level. As an EV-Gantt is derived from WBS, this enables multilevel-portfolio management and lets the senior manager of the project to centralize their monitoring process to a single interface.
Agile methodology followed by Kanban board presented in [30] utilize stages while simulating the projects. Each stage of the project is represented by a separate lane, and progress is evaluated by moving the work from one lane to another. The author uses a pull system to monitor changes in agile projects using EVM analysis and the basic principle of agile to identify the current value at a given point in time and compare it to the planned value.
EVM uses baseline activity at the bottom of Work to break down the structure to measure the periodical progress of the project. Thus, the EVM methodology uses the top-level of WBS information with a so-called top-down approach. This top-down approach was further investigated by an author to compute the longest path and applying multilinear-regression methods at different intervals of the project. Using this top-down control approach, the PM could take corrective actions without drilling down each activity. WBS does not reflect changes in the project, however it describes the use case point (UCP) as a baseline for the performance measurement of the project. In this proposed approach EVM analysis utilize number of UCP and variety of work task involved to get planned percent completion (PPC) of the project [37]. This PPC is used to get the PV as shown in eq ''(3)''.
(3) Table 1 summarizes the existing techniques or tools used to measure the performance of the project. Although these approaches work well with already defined requirements to measure the performance of the project in term of time, cost, quality and work product with features and functions. However, there is no such tool which could gauge the performance of the project in its completeness and incorporate volatile nature of scope. As was pointed out in aforementioned literature that EVM is used to control time and cost, it is important to note here that EVM is not used to control the third constraint 'SCOPE'. In addition, the EVM methodology can be integrated with the risk management, this integrated approach offers a novel mode to manipulate the project under uncertainty. EVM variables and variances talk about what went on in the past, whereas, the area of risk management is concerned with the future event of the task. In article [41], authors incorporated two perspectives under the same framework, so that the PM could learn effective decision during the execution of the project. EVM methodology is also used with schedule risk analysis by developing a simulated software to replicate uncertainty in the environment [42]. Variability in the project can be estimated during planning phase of the project by simulating universe of the projects using Monte Carlo simulations, therefore, during execution of the project by using planned or expected variability, overruns in the project could be forecasted within this variability [43]. Indices and variance used by EVM only provide the information like the project is delayed or over budget, however they do not provide appropriate information that the overruns are within the expected variability or not. If they are not, corrective actions should be taken, such as some structural changes or some unexpected events could occur during the execution of the project. To this aim, two control indices are introduced: Cost Control (C Col ) and Schedule Control index (S Col ). Using these indices EVM depicts high value if project was running under uncertainty [44].
In 2014, a graphical framework was proposed to measure uncertainty in the project by generating universe of the projects, it generates all possible variations of a given project schedule and associates probability with it. At any instant of the project progress 'x', triads are defined. The triads defined the state of the project with respect to percentage completion of the project to calculate time and cost spent when the project is completed at x%. Once the distribution is computed, it is possible to calculate different percentiles (time and cost) of the project by varying value of 'x' for each standard deviation. By joining the percentiles of cost and time rectangles are formed. In each rectangle project is computed according to the probability of time and cost and it could lead us to identify that project risk is under control or not within its rectangle [45].
Limitations of Traditional EVM: As, it is explained in the aforementioned literature, EVM is used to identify deviations in time and cost, a detailed analysis of budget and schedule is performed by simulating universe of the projects [45], however, it does not include scope into its analysis. Although, WBS is used for time and CBS (Cost Breakdown Structure) is used for budget of the project. jointly they are used to increase the performance of the project [39]. However, WBS uses deliverable information and limited to incorporating the volatile nature of scope as requirements could not certainly belong to WBS. Concluded that, EVM utility has been questioned while for the scope of the software project. Therefore, there is a need to further investigate from state-of-the-art, why EVM doesn't measure deviations in project scope, directly? To answer the aforementioned question, there is a need to look into the literature on scope definition tools and techniques.

B. SCOPE DEFINITION TECHNIQUES/TOOLS
Scope definition involves boundaries and limits of the project [47]. It enhances the performance of the project with respect to budget, schedule, success and failure of the project. In existing literature, different techniques and tools were used to monitor and control the project scope, along with majority of the software failures. Most of these tools are used to either verify, estimate, monitor and control scope definition including Function point (FP) analysis, Expert judgement, Performance analysis and Work Breakdown Structure (WBS) etc.
Feature breakdown structure is a tool employed to determine the division of work in a proper pattern, it also aids in defining and controlling the scope. There are some simple tools which are utilized to support the management and iteration task in term of time and effort. They provide useful charts like Burn Up and Burn-down to monitor the progress of the project. Burn-down chart provides the information about the remaining work left for the project and suggests quick changes regarding scope information to lets the project back on track. It also offers service to monitor the change information and frequency of modification in the project regarding the scope of the project. Burn Up chart is alternate of burn-down charts as it offers information about the amount of work done while measuring the incremental progress of the project [46]. Function point (FP) analysis is used for estimation of scope and while estimation it only considers the requirements [48]. WBS is used as a verification tool for project scope. It basically uses user/system requirements and provides resource and task for cost estimation [49]. However, it is limited to gauge the requirements and tasks into deliverable. Because deliverables and tasks can be broken down into requirements but these requirements could not certainly belong to WBS. Story mapping is a tool used to control the scope of the project as well, it provides a bit of user stories in the product backlog while verifying the scope of the project [54].
In software projects, modifications are considered agreed upon scope of the project. These modifications are due to inevitable change and complexity of the project scope. According to [50] author ''Half of the system requirements change till deployment''. This bring us to the issue of project planning because formulating a baseline project scope accurately is crucial due to its ever-changing nature. Aforementioned technique/tools work for scope definition regardless of quantifying the completeness of project scope. These tools aid practitioners only to manage the scope that is already defined. None of these existing tools could gauge the completeness of project scope except in [61]. The detail of these techniques/tools are provided in Table 2.
In [61], the completeness of scope definition is used to explain with the help of a tool named as ''Software Project Scope Rating Index (SPSRI)''. In this study, the author has divided project scope into 45 critical elements; all the elements are generic so that every type of software project scope can fall into it. These 45 elements were used in essence of defining scope in its completeness. While considering the elements critical for the software projects, the aforementioned tool assigns rank and weight to SPSRI elements. It considers frequency (fi): occurrence of an element in the research articles, rank (ri): importance of an element from 1 (most important) to 45 (lest important), and weight (wi) which shows the contributions of each element towards the total scope score (Tscr). In order to evaluate the scope definition of the project, a five-point Likert scale (0-5) was assigned to get the score-card of each element depending on their quality. The list of SPSRI elements and their score-cards are briefly explained in Appendix B.
Limitations of existing Techniques/Tools for measuring Scope Definition: Most of the existing techniques/tools discussed in the literature are used to monitor and control the scope also some of the approaches such as SLOC, Delphi method and object point are used to estimate the cost of the project using similar previous projects and aid practitioners only to manage the scope that is already defined. None of these existing tools could gauge the completeness of project scope except SPSRI, which claims the completeness of project scope [61]. Although, the elements defined by SPSRI incorporate changes in scope of the project, however, these elements are limited to estimate effects of changes in scope on the project plan. The literature indicated that modifications in scope have an inevitable impact to its end product. This may lead us to adjust the project plan accordingly to meet the new requirements. Volatile nature of scope and its possible effects on the project plan have already been established in Section 1. However, a thorough investigation needs to be conducted to identify scope change's effects on the project plan.
This research purpose a method to identify deviations/changes in scope by adopting the SPSRI tool, as claimed of calculating the completeness of the project scope. Furthermore, scope changes effects will be mapped and quantified with SPSRI elements along with its integration with EVM to forecast deviations in scope for estimating the status of scope during run time execution of the project.

III. RESEARCH METHODOLOGY
This research aims to propose a method to identify the effects of change in scope on the project plan also aid PMs to forecast deviations/changes in scope with the progress of the project. Research questions presented in Section 1 lead the research. The research method is divided into five key steps: 1) Literature Review, extraction of scope changes effects 2) Mapping of effects with SPSRI elements, 3) validation of mapping, 4) Proposed Method, Quantification and integration of SPSRI elements into EVM to measure deviations/changes in scope, and 5) Evaluation of results. The steps along with their inputs and outputs are shown in Fig. 2.

A. SEARCH SOFTWARE SCOPE CHANGES EFFECTS
To achieve RQ-1, a thorough literature review was conducted to address the effects of changes in the software scope of the project. Various factors were identified related to changes in scope, including; scope creep, requirement volatility, requirement uncertainty, ambiguous requirements, risk mitigation, hardware; and software failure, de-scoping, technological uncertainty, pre-defined budget, schedule pressure, resource competency, poor scope management, lack of decision making, early estimate and low development involvement.

1) SEARCH STRING
To measure the effects of changes in scope, four renowned online databases, i.e., IEEE Xplore, Science direct, Springer-Link and Google scholar were searched. Criteria for the search string used and selection of papers are discussed in Table 3 2) EFFECTS AND THEIR DESCRIPTIONS All the effects were explored from the researched articles as shown in Table 4. Consequently, 27 effects were identified. These extracted effects were first collected and afterward combined into a simple, unique effect based on their similarity to establish an integrated list. As a result, 17 unique effects were chosen. On exemplary basis, the effects, such as shortage of labor, shifting of resources, availability of resources, and physical damage of hardware and supplier issues were taken under a single unique effect named change project resources. The process was repeated until distinctive effects were attained. These extracted 17 effects are referred to as the effects of software scope changes. Additionally, effects extracts from the literature were then developed in the course of proper definition for a clear understanding of those   effects. A complete list of effects along with their description is available in Appendix A.

B. MAPPING WITH SPSRI ELEMENTS
A complete list of scope change's effects that were selected in the previous section was finalized to map with the completeness of scope elements. As it was highlighted in Section 2, SPSRI is the only tool that claims to gauge the completeness of project scope. This research uses SPSRI elements as a baseline to closely understand the individual effects of modifications in the scope of the project plan. To accomplish the second main objective of this research, literature-based mapping was performed between the extracted effects of the scope changes (denoted as ef1, ef2,..ef17) and SPSRI elements (denoted as e1, e2,..e45). This could guide us to examine the possible effects against each scope element, also mapping of the results were evaluated against questionnaire collected from different software houses. A complete mapping list of extracted effects with SPSRI elements is available in Table 5.

1) VALIDATION AND PRIORITIZATION OF MAPPING
In the previous section, we have established a literature-based mapping of SPSRI elements with the extracted effects. This section provides the evaluation of mapping and to prioritize the effects based on their importance. The mapping of SPSRI elements with extracted effects was validated and prioritized to check if the identified effects influence respective SPSRI elements through a survey. Although, we have used the top eight, most contributing scope elements in this research to avoid complexity, however, the identical methodology can be adapted for the rest of the scope elements. For the survey different companies were considered. The questionnaire was conducted locally in the software industry of Pakistan and the main targets of this survey were the PMs and the senior developers.
The questionnaire was sent via email, were 4-5 PMs had more than 15 years of experience and 10-12 senior developers had more than 7-8 years of experience in software development. The overall conclusive results of this survey are shown in Fig. 3. Formula used for calculating the mean of responses against possible effects for top selected eight SPSRI elements is given below: where, w i is the weight assigned to the options in the questionnaire and x i is the number of respondents. The results of descriptive statistics not only provide the most influencing effect against each scope element but also provide the mapping validation with SPSRI elements. As in the questionnaire, options provided to the respondents for prioritizing possible effects against respective SPSRI elements were: 1-Strongly Agree, 2-Agree, 3-Neutral, 4-Disagree, 5-Strongly Disagree.
The questionnaire was developed by adopting the guidelines of Rattray and Jones [89]. It was composed of two sections; the first section was about the demographics of respondents, whereas, the second section was comprised of mostly contributing eight SPSRI elements. The demographics information of the respondents is provided in Appendix C. Moreover, these elements were followed by multiple effects. The descriptions of these effects is shown in Appendix A. This part of the questionnaire was designed in a way that respondents were asked to give their views on a five-point Likert scale to find out the importance of effects against each SPSRI element.
However, before showing the results of mapped effect, it is important to check the questionnaire: • Reliability: By the Cronbach's alpha. • Validity: By the descriptive statistics to find the influence of each effect.

a: RELIABILITY
To find out the internal consistency of the questionnaire (how questions are closely related collectively), Cronbach's alpha (Cα) was measured. The rule of thumb defines alpha coefficient in the following ranges [90], [91].
The alpha coefficient for the proposed questionnaire was 70 approximately, which is considered acceptable. Therefore, the questions have relative internal consistency. The idea behind this survey was to evaluate the mapping, that either the PMs and senior developers agreed with this or not and the other point of view was to highlight the most influencing effects against each SPSRI element.

b: VALIDITY
As a result of 37 responses were gathered, then to summarize the results of the survey descriptive statistics approach [92], [93] is used for the collected responses of each effect against their respective SPSRI element. It can be seen that, for the mapping of effects, more than 50% of the respondents reported effects as agreed against the particular scope element. Only one effect, e7 against project mission was reported as 40% agreed and 35% neutral by most of the respondents. Based on this survey, it was concluded that all extracted effects had significantly influenced on software scope of the project. The result of mean values calculated using descriptive statistics are shown in Table 5, bold values (values greater than mean values) were considered ranked among the un-bold values (values less than mean values). It is evident from the Table 6 (025) effect showed priority as an influencing effect for Project Schedule as compared to other possible effects. These values show the priority of each effect against their respective SPSRI elements.

C. QUANTIFICATION OF EXTRACTED EFFECTS
After the mapping of Extracting Effects with SPSRI elements, there is a need to represent them in a mathematical form. This mathematical form is used as an input for quantification of scope change's effects. Here, it is also significant to recognize that how these extracted effects are to be structured to build a diagram that can be used as an input to evaluate the effect of the change in scope on the project plan. One of the primary reasons for scope changes is due to lack of understanding of the problem in the planning phase and complexity of a project. These hindrances could lead to a change in project goals, resources, estimates, and timelines, and so on.
To answer the RQ-3, we have selected possible effects against each SPSRI element (Table 5) for mathematical modelling to estimate the expense of change in scope when different effects encountered due to the volatile nature of the project scope. The mathematical modeling of two SPSRI elements is shown in the example below. VOLUME 8, 2020

1) PROJECT MISSION
Scope definition defines the project mission employing four main variables such as; requirement management, team consensus, project goals, and needed objectives as indicated in Fig. 4(a) These variables have some definition levels and effects. When change is introduced, the definition level varies with variations in effects. The variations in effects are characterized by a change in the funding plan and timetable of the project.
where, Pm is project Mission Eefi= expense on ith number of effects RM: requirement management GO: goals and objective PR: product requirements SI: stakeholder interests

2) STAKEHOLDER EXPECTATIONS
Identification of key stakeholders, intentions and long-term expectations about how the system will help their interests are incorporated into the definition of Stakeholder expectation as shown in Fig. 4(b). Changes in business needs, business benefits and marketing needs that could be required to gain business benefits would change stakeholder involvement and interest towards the project along with the documentation of planned work packages. These modifications initiate underlying change, which consequently has influences in project funding requirements.
where, Se is the stakeholder expectations Eefi = expense on ith number of effects PD: project documentation SI: stakeholder interest In this paper, we propose a framework to monitor and control the effects of changes in scope on the project plan, adapted from the article [45]. We simulate the universe of the project using Monte Carlo simulations and compute statistical distribution functions of the scope's score and cost for given project activity and gather the data in the form of percentage completion of the project. Applying this information, we could identify what degree of deviation presents with the project at each checkpoint. The primary aim of this research is to identify deviations/changes in the project scope at run time within the ''expected variability (planned)'' deducted from the variability of the project activities. Variations in project scope at a given project budget were computed using the aforementioned extracted effects as shown in Fig. 4, by using eq ''(5)'' and ''(6)'' to get definition level (dl). Taking over a particular distribution function of scope's score and the cost, we can calculate the statistical distribution functions of the scope's score (updated definition level (dl')) and cost using Monte Carlo simulations (as shown in Fig. 5). When several projects are run through simulation up-to j th simulation and at the end of the project scope's score is represented as S j and cost is as C j as shown by a point in Fig. 5. Within this scope-cost graph, the universe of the projects is generated through simulations; We can get the area of possible of scope's score and cost of the project, thus we can compute the statistical distribution functions, one for the scope's score (horizontal distribution at the top of Fig. 5) and one for the cost (vertical distribution at the right end).
Once the distribution is computed we can calculate any confidence interval and percentiles for scope's score (P s 10, P s 30, P s 70, and P s 90) and cost (P c 10, P c 30, P c 70, and P c 90), mean values (S MEAN , C MEAN ) and other statistical features like the rectangle of a respective percentile. These rectangles are made by joining the percentiles of the scope's score (P s 10, P s 90) with a percentile of cost (P c 10, P c 90) of the project (represented by a solid rectangle in Fig. 5).
Using simulations, we could identify at the end of the project that the project is under control or not, however, this information is required during the execution of the project. We have adapted the concept of triads (x % , S xj , C xj ) from [45], where x is the percentage completion of the project, C xj = x*C j is the amount of money that has been spent when a project is completed at x % , S xj is the scope's score of the project when cost C xj has been achieved. C j is the total cost of the project at the j th simulation. For example, when x = 0.5 it represents 50% completion of the project with triad represent as (x 50% , S 50 , C 50 ). Similarly, if the triad is split into two-dimensional graphs, a Cartesian axis of (scope's score, cost) could be obtained with the different distribution of the project up-to corresponding 'j' simulation till the project is 100% completed at x=1. VOLUME 8, 2020 FIGURE 6. Graphical representation: triads and projections (Scope's score and Cost) [45].
The percentage completion of the project ('x') used triad is consistent with the EVM methodology. As cumulative planned cost pointers the work performed, therefore EV= current start PV(completed), at any instance of 'x', project completion can be calculated knowing the EV and BAC of the project. We have calculated the percentage completion of the project by using EV/BAC. Using different instances of 'x' we get the area having a different distribution of cost and scope's score. In other words, the statistical distribution of cost and scope's score is created using x=1(represent the stage at the end of the project). For each x numbers of j simulations were run through Monte Carlo simulations and defined triads. Thus, for each x, by varying influencing factors (scope's score (using dl)) we can obtain a desired percentile of the project scope.
In this paper a case study is used to illustrate this approach and distribution function of scope's score and costs were computed by using them as dependent and independent variables as long as scope's score-accumulated cost trajectories are stimulated. We were interested in knowing the deviations in the scope of the project during its execution and when we take the ''expected variability'' into account during the monitoring period through the EVM methodology. If the project is within the percentiles or confidence intervals, scope variances can be explained by normal stochastic variability, however, if the project is outside these intervals, something out of the planning may happen and PMs need to take corrective and timely action depending upon the context of the project, for instance, scope baseline and timely delivery of the required deliverables may need appropriate size of the buffer to control the project.

1) SCOPE's SCORE AND COST PROJECTIONS
As the methodology is coherent with EVM. So, the graph generated through EVM could easily be incorporated into graphical framework [45]. When we put the information into this framework two Cartesian planes are formed one with the cost of the project (x, c) (represent in Fig. 6.b) and one with the scope's score of the project (x, s) (represent in Fig. 6.c). These projections are shown in Fig. 6. Fig. 6.a is the same as the projections of scope's score and cost are shown in Fig. 5, as different rectangles representing different percentile with different percentage completion of the project 'x'.
Once the distribution is computed, it is possible to calculate different percentiles of the project by varying the value of 'x' for each standard deviation. This includes percentile for cost (P c 10, P c 30, p c 70 etc.) and scope's score (P s 10, P s 30, p s 70 etc.). Using the percentage completion of project progress 'x', the project can be divided into respective percentiles of scope's score and cost. Continue with percentile, if we join the points of a percentile of cost (e.g. P c 30. . . etc.) with a percentile of scope's score (e.g. P s 30. . . etc.) rectangles are formed. Each rectangle is formed using a particular percentage completion of the project process (25%, 50%, 75 %, and so on). The red and blue rectangle in Fig. 6 shows 75% and 100% completion of the project respectively. By incorporating data into the aforementioned rectangles, changes in the project can be forecasted concerning different percentage completion of the project.
In 6.b, projections of the cost are shown, using percentage of project (x) in x-axis and cost on y-axis. For each value of x, we have computed different percentile for cost P c C, C ∈ [0, 100] and then join points for a particular percentile C, P c C, for all x ∈ [0, 1], obtaining a straight line as cost of the project is correlated with the percentage completion of the project as shown in Fig. 6.b.
In 6.c, projections of scope's score are shown, using percentage of project (x) in y-axis and scope's score on x-axis. For each value of x, we have computed different percentile for cost P s S, S ∈ [0, 100] and then join points for a particular percentile S, P s S, for all x ∈ [0, 1], obtaining the curves as shown in Fig. 6.c. Fig. 6 builds up during the planning phase of the project. The necessary input to build the figures are only the scope's score and cost distribution functions of the activities and its precedence relationship. The information of scope's score gathered using definition level (dl) of respective scope element from the score card, that is, the common information needed for scheduling, budgeting and scoping of the elements in uncertain environment.

E. CASE STUDY
In this paper, we have identified the effects of changes in scope by generating variations in project scope at a given budget of the project. In order to gauge variations in project scope, SPSRI elements with their possible effects were considered (discussed in Section III-C). An already implemented case study was adapted from [45] is used in this research. We have demonstrated the case study using commonly used scheduling techniques in the literature PERT or CPM, however, any other scheduling technique could also be used as a benchmark. In this case study, two planned values PVs were drawn: one PV is collected using the PERT scheduling technique (named as PV PERT ) and another PV is collected using a mean of all the simulations (named as PV MEAN ). The steps of performing simulations are shown in Fig. 7. We have generated stochastic instances of the project, being each instance with possible realization with its scope's score and cost. Once we get the distribution, we could identify mean, variances and percentiles of the project with the progress of the project 'x'.

1) SELECTION OF SPSRI ELEMENTS
When gauging the completeness of the project scope, not all the 45 elements are vital that contribute towards the accomplishment of the project's success. Article [61] assigns rank and weight to SPSRI elements, while considering the element critical for the software projects. To evaluate the scope definition of any software project, a five-point Likert scale was used to get the score of each element depending on their quality. The list of SPSRI elements and their score-card was briefly explained in Appendix B. This shows the contribution of each  Table 8 were selected for scheduling. The selection of the aforementioned eight elements is due to their highest weight in the score-card, as they show maximum contributions towards the project success.

2) ELEMENTS SCHEDULING
In the light of past research to compare different methodologies for monitoring and controlling, we have selected a project model represented in Fig. 8. This Activity-On-Node (AON) network had been used in literature to identify the effect of information presentation on project control. Moreover, this distribution is used by the author in his previous research to monitor and control uncertainty in risk by generating all possible variations of a given project schedule [45]. Table 8 includes a planned work package, each element has its expected duration and cost. This information is used as a baseline in the hypothetical case of the executed scope of the project. Fig. 8 shows the AON network diagram adapted from [94]. In the AON network, durations are displayed as exponential rather than typical appropriation (normal distribution and beta distribution). In literature, the exponential distribution is used to identify uncertainty in the project [45]. Similarly, in our case, this type of distribution helped us to understand deviations/changes in scope for particular project progress x in which dl varies to its baseline. Using this information, we can forecast and compare overruns in the project for an optimistic method like PERT analysis.

3) ASSIGN SCOPE's SCORE AND COST TO THE ELEMENTS
Initially, each selected SPSRI element is assigned with a scope's score and cost to get a baseline plan (represented as PV). The score is assigned to each of the SPSRI element depending on the quality of their explanation. In [61] quality is referred to as definition level (dl) and a five-point scale from (0-5) is defined for determining dl. The definition level (0-4) of each SPSRI element along with the score-card are discussed in Appendix B.
The next step of the proposed methodology is to generate universe of the project by means of Monte Carlo simulations and get the data into percentage completion of the project (discussed in III-D.

4) USING FRAMEWORK AT PROJECT RUNTIME
We have created over 10,000 simulations and have generated PV PERT and PV MEAN . We need to represent these PV s in the graphical framework. The planned value (PV) can be represented directly into cost-scope's score plane (represent in Fig. 9. By summing up cumulative planned EV calculated. These basic tree indices of traditional EVM are shown in Fig. 9. When we put the information into this framework two Cartesian planes are formed one with the cost of the project (x, c) (represent in Fig. 10.b) and one with the scope's score of the project (x, s) (represent in Fig. 10.c). At any particular score of the scope s, the planned value calculated as PV s , and therefore x s =PV s /BAC, BAC is the budget at completion of the project. These points are shown in Fig. 9 as (x s , PV s ) in (see Fig. 10.b) and (s,x s ) (see Fig. 10.c). In addition, Fig. 10.a) is same as shown in Fig. 9.
At any instance of 'x', project completion can be calculated knowing the EV and BAC of the project. The data were arranged into a two-dimensional graph knowing that for S=AS (actual scope's score), the performance of the project (PV AS ) and percentage (x AS = EV AS / BAC) of the project was obtained by joining the points (x AS = PV AS ) in Fig. 10.b and (A S = x PV ) in Fig. 10.c.
To find the variations in project scope at a given budget, percentage completion of the project used and split the information into triad (x % , S xj , C xj ) was used. The triad was divided into a two-dimensional graph or in the form of a Cartesian product of the percentage, cost (x % , C xj ) and percentage, scope's score (x % , S xj ) by varying the value of 'x' as shown in Fig. 5.
As the methodology is coherent with EVM. So, the graph generated through EVM could be easily incorporated into authors graphical framework presented in [45]. When we put the information into this framework (shown in Fig. 6) two Cartesian planes are formed; one with the cost of the project (x, c) (represent in Fig. 10b.) and the other one with the scope's score of the project as represent in Fig. 10c.). In Fig. 10b.) we get the straight line between the cost and percentage of the project, as cost of the project is correlated with the percentage completion of the project. At any particular scope's score s, the planned value calculated as PV s , and therefore x s =PV s / BAC, BAC is the budget at completion of the project. These points are shown in Fig. 10 as (x s , PV s ) in (see Fig. 10.b) and (s, x s ) (see Fig. 10.c). As, the data lie under the normal distribution curve, therefore, mean and standard deviation, etc., were calculated. Values of cost near the mean have high confidence interval while values far away from the mean have a low confidence interval, i.e., a high value of the standard deviation confidence interval gets lower. Using this framework, normal distribution and confidence intervals of cost and the scope can be determined for any project progress 'x'. Once the distributions have been computed, we can compute statistical features like confidence interval and percentiles for the cost (for example P c 10, P c 30, etc.) and scope's score (for example P s 10, P s 30, etc.) for the project.
At s=250, cost of the project is 11400 and percentage of the project completion at 80%, the project is over-cost, as cost of the project is higher in the PV projection at that particular scope's score (shown in Fig. 11.b as (over cost PV)). However, the project remains within its rectangle P c 70 and P c 90 (using yellow and red lines respectively). This means that taking into account the assumed variability of cost and scope's score, the project is under cost (using a confidence level of 90%). If we narrow the confidence level towards 70% project, the project is over cost. This 70% confidence level is the point where the PM should take into account to check what important changes happened in the project regarding PV.
At s=250, P s 90 (confidence level at 90%) project is ahead of baseline scope as shown in Fig. 11.c, the project is on the left side of the red lines. Using 30% and 70% confidence level represented as P s 30 and P s 70 (using orange and yellow lines respectively), the scope of the project is behind.
Using PERT methodology, the scope's score estimated for the completion of the project is 170 units by using Monte Carlo simulation the probability to complete the project before aforesaid scope's score is very low. According to Fig. 11, with 80% of the work performed, the scope's score is 120 unit behind with respect to PERT technique and 40 units behind as compared to P s 70, however, a project is ahead of scope's score regarding P s 90. Likewise, the project is over-cost of 5,800 concerning P c 30 and over-cost of 4,800 relating to PERT estimation technique and has under the budget of 600 regarding P c 90.

IV. EXPERIMENTAL EVALUATION
These simulated results were statistically proved using 'Multi-linear regression' test. This test not only finds correlation between the dependent variable (overall cost) and independent variable (SPSRI elements) but also identifies the contribution of each element on the overall cost of the project (Discussed in Subsection IV-A). Exiting theory of project manager holds that the triple constrains of time, cost and scope are interrelated with each other. Change in the project often lead to changes in the budget and schedule information of the project. Meanwhile changes in scope will lead to corresponding changes in budget and schedule of the project (as shown in Fig 12).
All the selected elements showed their contribution on increasing the overall cost of the project. Four Models were generated that are as follows. Before the implication of regression linear model, the normality of the data was VOLUME 8, 2020   evident. The simulated data is normally distributed as shown in Fig 13. In Subsection IV-B we have highlighted the performance measurement of the existing framework as compared to the proposed one using variances proposed by traditional EVM.

A. REGRESSION MODEL INTERPRETATIONS
Dependent variable: Total Cost Model 1, Model 2 and Model 3 explain the overall cost 25%, 47% and 53%. Therefore, model 4 was only considered as it explains the overall cost 57% approximately. Table 9 and Table 10 show the contribution of independent variables upon dependent variable and correlations between them, respectively. Only Model 4 is considered, as it explains the dependent variable 57%. The detail description of the model/s is as follows,  To compare variations in scope, the already proposed framework in [45] was selected. This framework generates all possible variations of a given project schedule using Monte Carlo simulations and associates probability with it. It identifies deviations in the project schedule at different project progress 'x' and gathered the data in the form of percentage completion of the project. We have implemented article [45], proposed framework by considering over 400 simulations as shown in Fig. 14. We have created over 400 simulations by varying the schedule of the project and drawn two PVs; PV PERT (using PERT scheduling technique) and PV MEAN (using simulations). Percentage completion of the project progress 'x' is consistent with traditional EVM. As cumulative planned value pointers to the work performed, therefore EV= current start PV(completed). The black line in Fig. 14, shows the performance of the project (computed through simulations represented as PVMEAN) and the pink line (Computed using PERT scheduling technique) drawn to show the progress of the project as compared to its baseline. These basic indices (PV, EV and AC) proposed by traditional EVM are shown in Fig.14.

Model 4:
When we put the information into this framework two Cartesian planes are formed one with the cost of the project (x, c) (represent in Fig. 15.b) and one with the schedule of the project (x, t) (represent in Fig. 15.c). At any instance of 'x', project completion can be calculated knowing the EV and BAC of the project. The data were arranged into a two-dimensional graph knowing that for t=AT (actual time), the performance of the project (PV AT ) and percentage (x AT = EV AT /BAC) of the project was obtained by joining the points (x AT = PV AT ) in Fig. 15.b and (AT = x PV ) in Fig. 15.c.
At t=15, cost of the project is 8500 and percentage of the project completion at 75%, the project is over-cost, as cost of the project is higher in the PV projection at that particular time (shown in Fig. 15.b as (over cost PV)) however the project remains within its rectangle P c 70 and P c 90 (using yellow and red lines respectively). This means that taking into account the assumed variability of cost and schedule, the project is under-cost (using a confidence level of 90%).
At t=15, P d 90 (confidence level at 90%) project is ahead of schedule as shown in Fig. 15.c, the project is on the left side of the red lines. Using PERT methodology, the duration estimated for the completion of the project is 11-time units, however, simulation result shows limited chances to compete the project before the said date. According to Fig. 15, with 75% of the work performed, the delay of the PERT schedule plan is 8-time units and 2-time units as compared to P d 70, however, a project is ahead of schedule regarding P d 90. Likewise, the project is over-cost of 2400 concerning P c 30 and over-cost of 1300 relating to PERT estimation technique and has under the budget of 800 regarding P c 90. By incorporating data into these rectangles, uncertainty /changes in project can be forecasted with respect to different percentage completion of the project. This framework identifies uncertainty or changes in risks by generating all possible variations of project schedule. Moreover, it used as a control tool as the project remains within its boundaries if compared with percentile P90.

1) EVM PERFORMANCE MEASUREMENT W.R.T TIME AND COST
In order to identify the change information for the PMs who are more interested in the cost and schedule variances rather than absolute values. For this, we use PV line represented as the performance of the project on x-axis and drawn deviations in the project using this reference point. The percentile VOLUME 8, 2020 (P c 10, P c 30, P c 70 and P c 90) represented as XCV for cost variance (Fig. 16) and XSV for schedule variance (Fig. 17) respectively. In these aforementioned graphs, we represent evolution in the project with respect to its PV. In each period of the project, we can clearly see the control and status of the project. In both cases delay in term of cost and schedule of the project is also available. Moreover, the project seems stable with respect to percentile P70 and P90. This analysis provides limited to include deviations of scope during run time execution of the project into this EV performance analysis.

2) EVM PERFORMANCE MEASUREMENT W.R.T SCOPE AND COST
The performance measurement used for traditional EVM is calculated using performance of the project (PV mean) as a reference point on these aforementioned percentiles explained in Fig (11.b) and (11.c) (see black line). The percentile of cost (P c 10, P c 30, P c 70 and P c 90) represented as XCV for cost variance (Fig. 18) and Percentile of scope's score (P s 10, P s 30, P s 70 and P s 90) represented as XS s V for scope's score variance (Fig. 19) respectively. The percentiles of performance variances are drawn using percentage completion of the project progress 'X'. In these graphs, we represent evolution in the project scope with respect to its initial scope information gathered at the start of the project. At 25% completion of the project, a clear deviation in scope score and cost can be seen in both of these graphs. In other words, project is behind the planned scope and over budgeted with respect to its baseline with respect percentiles 10  and 30 (shown with blue and brown lines respectively). However, the project remains within the confidence interval with respect to percentile 70 and 90 (represented by yellow and red lines respectively). Therefore, this EVA is used to control the performance of the project within its boundaries.

V. DISCUSSION
Although EVM methodology measures the deviations in budget and schedule of the project, however, due to the problems of scope, i.e., scope creep, de-scoping, over-scoping, etc., it does not incorporate deviations/ changes in scope. Thus, there is a need for a dynamic EVM that incorporates the volatility of project scope. This research tries to alleviate the aforementioned problems by including the traditional EVM with SPSRI elements. An extensive literature review is conducted to identify the effects of change in scope on the project plan. These extracted effects are then mapped to SPSRI elements to identify the influence of changes against each scope element. When change is introduced, the definition level varies with variations in scope change effects. These scope changes effects, characterized by change in funding plan and timetable of the project are briefly discussed in Section I and Section III-C. To recap; • RQ-1: What are the state-of-the-art scope changes effects on the project plan? This study was set out to find a method that could quantify the effects of changes in scope on the project plan. Literature has discussed the cause and effects, and problems related to the change in scope. Moreover, these effects work regardless of incorporating the ever-changing nature of scope. Another viewpoint is that there is no such method that could quantify the completeness of the project scope. Although the EVM methodology measures the effects of changes on the project plan, a detailed analysis of budget and schedule is considered by simulating the universe of the projects. However, it does not include the scope in this analysis or other words, it does not directly measure changes in the software scope of the project. These changes are due to the volatile nature of project scope, whenever, there is a change in scope it affects the project plan. Thus, scope change effects were searched in each research article to incorporate the ever-changing nature of scope problems which resulted in the extraction of 17 unique effects based on the software scope of the project.
• RQ-2: What are the possible effects of scope changes against each scope element?
According to the Project Management Institute, triple constraints (scope, time, and cost) of project management defines the success criteria for the project. The performance of the project could be efficiently gauged using these aforementioned constraints. Existing literature discusses the effects of changes in requirements for the project plan, especially budget and schedule, however, limited to consider the third constraint ''scope''. Whereas, the scope is the most significant reason for project success or failure. Therefore, there is a need to look into the literature on scope definition tools. Through an extensive literature review, it was conducted that there has been no such tool that could quantify the completeness of the project scope. Moreover, few of the tools worked without gauging the completeness of the project scope; other aid practitioners to manage the scope that is already defined in the project or control the changes in scope once it gets baselines. The scope of the project is volatile, whenever, there is a change in scope it affects the project plan. To measure the impact of changes in scope on other constraints of project measurement, there is a need to identify a method for deviation/changes in scope.
After extracting the effects of changes in scope, conducted in RQ1, there is a need to have such a method that could gauge the completeness of the project scope. Recently, a tool named as SPSRI has claimed the completeness of the project scope, these SPSRI elements were used as a benchmark for scope quantification. If we have any other method that could gauge the completeness of project scope, it can be used as a benchmark alike. To determine the change in each SPSRI element, the mapping is performed between the extracted effects of changes in scope and SPSRI elements. This mapping is further validated by the software industry via conducting a survey. The idea behind conducting this survey was to validate the mapping from the PMs. More than 50% of responses were agreed with the mapping of SPSRI with the extracted effects of changes in scope. Additionally, descriptive statistics VOLUME 8, 2020 were applied to prioritize the most influencing effect against each SPSRI element.
To get the optimal solution, all the possible effects of changes in scope were used in this research i.e., completeness of scope elements (SPSRI elements) and triple constraints of project management. For example, if the research considered cost and scope, 'time' factor suppressed, and all uncertainty and changes associated with time are hidden. The same is the case if we consider the other two factors, then all uncertainty or changes associated with scope are hidden. It could not be possible to gauge the completeness of scope quantification if there have not any list of SPSRI elements. This research was started by extracting the effects of changes in scope to incorporate scope change problems. Due to the ever-changing nature of project scope, it is not possible to monitor and control changes in scope directly. Moreover, it is not possible to gauge the success criteria for the project, without considering the triple constraints of project management. This research will aid the practitioners to forecast overruns in the project using triple constraints of project management.
• RQ-3: How can scope variations be measured? In literature, WBS and FSM tools were applied by the practitioners for scope quantification. These tools have quantified the already defined scope of the project, in other words, literature overlooked the variations/changes in project scope. In the current research work, mathematical modelling was performed by considering the possible effects of each SPSRI element to represent the total expense of changes in scope. Moreover, in existing studies, SPSRI elements were assigned by a four-point scale (poor definition, major deficiencies, minor deficiencies, and complete definition) to calculate definition level for each scope element. To gauge deviations/changes in scope on the project plan, current research did not use any real-time project related to changes in scope because any real-time project could not gauge all possible deviations or changes in scope. Instead, we have used Monte Carlo simulations to generate the universe of the projects. Such projects generate all possible variations of scope's score for a given project budget and associate probability with it. These variations were then integrated with EVM to find the deviations to its baseline.
As our data was normally distributed, therefore, the statistical distribution of scores and cost was computed. After that, percentiles of scope's score and cost were drawn using mean and standard deviation for different percentage completion of the project progress 'x'. Continue with percentile, the project is computed according to the probability of a scope's score and cost. If we have information on the percentage completion of the project at any percentile, we can monitor the performance of the project and can determine if the project is under control or not. To overcome the complexity, we have used the top eight most contributing scope elements which covered 56.8% of the total cost while the rest of the variation is explained by other SPSRI elements. Our research is limited to identifying all possible variations of scope's score for a given project budget using the SPSRI elements. Therefore, complete list of elements can be used to generate all possible variations of given project scope's score and associate probability with it.
Furthermore, the results were tested using a multi-linear regression test to find the contribution of each element in increasing the overall cost of the project and a correlation between the dependent variable (overall cost) and independent variable (SPSRI elements). Additionally, this research establishes the statistical significance that these SPSRI elements have an impact on increasing the overall cost of the project.

VI. CONCLUSION
The EVM methodology uses budget and schedule information to monitor and control the performance of the project. The performance of any software project could be measured more efficiently by balancing the triple constraints of project management. Time and cost goals are normally straightforward; however, it is difficult to describe, agree upon and meet the scope of the project. Whenever a change is introduced, it includes the cost and schedule changes associated with the scope of the project. In this research, the effects of scope changes were recorded and incorporated into EVM to identify deviations in scope. To understand the effects of changes in scope, an extensive literature review was conducted. As a result of this review, seventeen unique effects were defined and mapped to SPSRI elements. This mapping process was literature-based and further evaluated from the software industry. The data of thirty-seven respondents were collected via a questionnaire instrument from the software industry. The respondents of this research were PMs and senior developers. The idea behind conducting this survey was to assess the most influencing effects against each scope element according to the industry. Top eight most contributing scope elements were as follows; 1) Project mission, 2) Stakeholder expectations, 3) Capable team member, 4) project schedule, 5) Initial cost estimates, 6) Technology, 7) Key deliverables, and 8) Business plan/vision were selected with their possible effects. Using descriptive statistics, it was concluded that project mission includes change cost and delay, stakeholder expectation includes project priority and change cost, likewise, capable team member holding change cost as a most influencing scope change effect.
The deviations in scope were used to gauge at the different percentage completion of the project. To forecast this, simulations were run to generate universe of the projects using aforementioned SPSRI elements and then results were integrated into EVM. This data was split into dimensional graphs i-e (PV s , x) and (x, s) and into different percentiles; percentiles of scope's score (P s 10, P s 30, P s 70, P s 90) and percentiles of cost (P c 10, P c 30, P c 70, P c 90). The result of simulations showed the project remains within its percentile at the different percentage completion of the project. Furthermore, the results were validated using descriptive statistics, independent variables (SPSRI) have influenced on dependent variable (cost) of the project. A multi-linear regression test was applied; this test not only provided us the correlation between the elements but also provided the contribution of each element on the overall cost of the project. Four models were generated, the result of the Model 4 showed project mission was the most contributing scope element on increasing overall cost of the project. In other words, for every one-unit increase in overall cost there was a 1.0008-unit increase in project mission. This model covered 56.8% the total cost while the rest of the variation is explained by other SPSRI elements. Correlation analysis illustrated that scope-score and cost variables strongly affect each other, and the effect of two variables (time and cost) could not be assessed without considering the third one. Our results were statistically proved (alpha <= 0.05) that selected scope elements have influenced on increasing the overall cost of the project.
In this research, only top eight most contributing SPSRI elements have been used for evaluation of mapping, which is a sufficient number for establishing the benchmark. Another limitation of this research is that mathematical modelling was performed to calculate the expense of change in scope, however, this model does not assign weights to the possible effects involved in the quantification of scope changes effects discussed in Section III-C. Project performance can be enhanced by assigning weight to the extracted effects.

APPENDIX A DESCRIPTION OF SCOPE CHANGE EFFECTS
ef1 Project Priority: Change request arises from the stakeholders due to change in dependency of the task and project deliverable, recorder along with its impact, and incorporated in redirection, reallocation and prioritization process which ultimately results in re-planning the scope of the project. Likewise, project priority and functionality change the project scope definition.
ef2 Lack of Motivation and Direction: Change can occur during the life of the project from analysis till the maintenance phase of the project and the stakeholders who are responsible for giving direction to the project by their individual's perception, cross-cutting of feature, priority and making requirements changes the scope definition of the project. This leads to a decrease in staff motivation and unmeet project deadlines.
ef3 Change Cost: While calculating the budget for the software projects, the focal point is on the number of programming statements and size of the project along with the customer's ability to pay for the labour, however, change in the results of the preliminary estimate on budget and schedule overruns and forced the development team to spend more time to finish the task. Variety in life cycle costing, unapproved scope, risk mitigation, initial estimates and adding more decision points to increase cost and reduce contingency reserved for the project.
ef4 Project Resources: The unavailability of newer technology to handle a change request can have problems reaching the project scope on time and budget. With the demand for new technology, all plans, estimates, schedules must be re-assessed and a new example or prototype must be designed to achieve the varied scope of the task. Moreover, change in resources with limited boundaries of the project goes to the scope creep and increases overhead for potential delays. This scope creep can lead to a technology creep problem for the developers.
ef5 Project Risks: Risks come from multiple sources like business risks, technological risks, supplier risk, technical risks, etc. These risks often occur when a team member stops working due to misconduct of required work tasks, inappropriate effort estimation, and emergency. Technological uncertainty, untried assumption constrains, requirement uncertainty and volatility (have an impact on project risk management) can direct blow-out cost afterwards.
ef6 Rework: Rework exists throughout the life of the project but possesses a maximum contribution during the requirement gathering phase. Factors that contribute to rework include lack of expertise, documentation deficiency, absence of communication, changes in requirements, absence of user involvement, and lack of adequate testing. Rework is the primary reason for schedule delays, budget overrun, unsatisfied clients, and risks even after delivery ef7 Schedule Delays: The number of breaks, waiting periods, third party tool providers, vague scope definition and poor documentation contributes towards lengthy lead time. Project success and failure are assessed and tracked against the prescribed schedule for the project. To change in model or prototype schedule estimates need to be re-evaluated.
ef8 Communication and Co-ordination Gaps: Unrealistic scope changes, trust issues, inappropriate sharing of documents and lack of decision making affect non-technical issues like communication gaps. On the other hand, continuous integration, client involvement, updating the requirement document reduce the level of over scoping.
ef9 Quality Issues: While developing the system and software product code smells refers to the poor technical selections that impact the quality of the code. Quality attributes (performance, security, reliability, availability, and so on.), requirement volatility (code quality, quality of project management and developer's capability) and lack of commitment affect project quality, as it decreases market share and brand value.
ef10 Lower Productivity: Workforce experience and forecasted completion date of the project affect actual productivity. During the run time execution of the project, an increase in workforce size and process, losses progressively decrease actual productivity.  [49] ef11 Failure to meet Customer Expectations: Customers are involved in scope definition, providing the feature, validating requirement, prioritization of the features, and change in the direction of the project. The ever-changing nature of requirements and low development involvement at early phases contribute towards expensive rework and failure to meet customer expectations. Customer involvement and documenting requirement are considered the important practices for reducing scope creep.
ef12 Poor Effort Estimation: Early estimate (based on vague requirements and re-estimation during development) and updating of system requirements to keep the documents updated, results in poor estimation.
ef13 Increase Effort: Implementing change request at a later stage of the project and effort required to mitigate uncertainty, requires mitigation effort and cost. In some cases, mitigation effort may increase than expected cost of the risk.
ef14 Effort Wasted: In software projects change in scope (over scoping, inappropriate equipment, ineffective process & methodology) is inevitable and commitment needs to be sacrificed, ultimately leads to time, cost, and effort overwhelms. The size of the same project is used as a benchmark to estimate the cost, schedule, and effort of the current project.
ef15 Project Failure/ Project Success: Slowly increase and change in software scope of the project influences the success of the project, due to its non-linear nature. Project success or failure has a direct relation with proper planning and well-defined scope definition. Unauthorized scope changes, lack of client and top management's involvement defining inadequate boundaries and unmanaged risks; result in project failure. Similarly, a well-defined scope control mechanism along with top management support leads to the success of the project.
ef16 Slow Down Project Progress/ Project performance: Project performance can be calculated using the progress of individuals or groups on performing their tasks and work items left. Frequent changes, vague and unstable responsibility, sustainability and tracking under the same team results in a slow down project progress.
ef17 Error Generation Rate: Schedule pressure and requirement volatility affect the error rate of the project, which is closely related to software evolution. With time, as fewer tasks remain to be processed, the software development rate falls identically affecting the error rate. Thus, an increase in error generation contributes to schedule and effort overrun.

APPENDIX B
See Table 11.

APPENDIX C
See Table 12. respectively, the master's degree in internet computing and network security from Loughborough University, U.K., in 2013, and the Ph.D. degree in computer science from King Abdulaziz University. He has over 11 years of working experience before attending the academic carrier. He is currently an Assistant Professor with the Software Engineering Department, College of Computer Science and Engineering, University of Jeddah, Saudi Arabia. His research interests include high-performance computing, big data, distributed systems, programming models, software engineering, and software testing. He is also the Vice-Dean of the Research and Consultation Institute for Development. His research interests include feature interactions detection and resolution in context-aware systems, smart homes systems, software engineering, the IoT, and data science. VOLUME 8, 2020