A Framework of Software Project Scope Definition Elements: An ISM-DEMATEL Approach

Software project scope definition is complicated due to the diversity and magnitude of the information needed. An inadequate scope definition often results in project failure as it continues to emerge as the major cause of delays, changes/rework, and cost and schedule overruns. Literature mentions different tools and methods to verify, quantify, and control software scope definition. However, none of these methods and tools help in defining a complete scope. Since a well-defined scope in the early stages is a core ingredient for project success, therefore, previously we developed a method that includes 45 elements of the software project scope definition. Although these elements are noteworthy for project scope, some may influence others; and should be concentrated on more when defining the scope of the software projects. The objective of this present study is that it builds on our previous research and uses Interpretive Structural Modeling (ISM) to extract the interrelationships among the elements and Decision Making Trial and Evaluation Laboratory (DEMATEL) to determine the intensity of these relationships. Experts from academia and the software development industry were consulted to identify the relationships among the elements. ISM-DEMATEL approach indicates that the project manager's competence is the main driver. Further, requirements, stakeholders' expectations, cost estimates, project schedule, resource estimation, project summary, communication, consultation, top management support are among the most influential elements that are critical to focus on. Moreover, the findings of the study provide project managers with a better understanding of the elements and their interconnections thus, helping in achieving a better scope definition.

SECTION I. Introduction

Over the years, the success of project management has been measured using the three metrics; time, cost and quality also called as “iron triangle” or “triple constraint”. While a project is considered to be successful if it satisfies the criteria of on-time, within budget, and according to the scope [1]. Software Project Management (SPM), a sub-discipline of project management plays a significant role in the development and successful completion of software projects. It involves the following activities: project planning, scheduling, budgeting, and risk analysis, etc. [2]. Project planning, which entails all the information about the project, concerning project deliverables, time, cost, communication, resources, etc., is believed to be a major contributor to the success of the project [2], [3]. During the planning phase, acquiring a precise definition of the project through the scope statement is recognized as one of the most important project management tasks, as it dictates the project’s success or failure [2], [4], [5].

Project scope signifies what needs to be done in the project and scope management is the management of what needs to be done [6]. Defining project scope, including all the work in sufficient detail to facilitate project execution, is considered complicated owing to the diversity and magnitude of information needed. Project scope definition requires two kinds of information: project-related information and product-related information [7]. It includes the do’s and don’ts of the projects, in other terms, it is the prospect of the project for all the stakeholders [5], [8]. Project scope definition has long been the subject of discussion for its significant relevance to project success [4], [9]–​[11]. A project’s success or failure heavily depends on its scope definition [4], [9], [12]–​[14]. To ensure smooth project execution, a well-defined project scope is considered critical [4]. It helps in successful resource allocations, better estimations, and provides a clear project roadmap [2]. Due to the dependence of schedule and budget on it, the importance of project scope increases further. It takes precedence over the constraints of schedule and budget as it is the most critical aspect of any project to recognize, and if the project scope is well understood, the other two essential constraints can be managed accordingly [15]. Consequently, a poorly defined project scope imposes a variety of adverse effects on the project schedule, cost, and quality [4], [15]. It has been found that incomplete or poor scope definition extends the project time and efforts, disrupts project rhythm, and lowers the morale of the project team [4], [6], [16], [17].

In software development projects, catering to the user, business or organizational needs has a significant influence on project success. Software scoping is a critical project process and project success is heavily dependent on the defined scope [16]–​[26]. For several years, software project management has become the focus of attention because of the significant percentage of project failures in the software industry [27]. One of the most crucial reasons for software project failure is not meeting the needs/requirements of the user [16], [25], [28]–​[30]. Lack of a clear scope definition has been recognized as a major cause of software project failure [4], [9], [17], [31]–​[36]. Few of the reasons associated with software scope definition are partial requirements, unclear objectives, changing requirements, impractical customer expectations [4], [13], [37], poor requirements [9], [38]–​[40], insufficient requirements engineering, poor planning, communication gap among stakeholders [41]–​[43], lack of user involvement, lack of planning [13], [44], [45]. It can be argued that vague or inadequate scope definition is a major source of risk for software projects.

Due to the significant role of scope definition in the success of software projects, the literature states various methods and tools that have been established to assist with scope definition. These methods and tools help in identifying the features of scope definition such as Work Breakdown Structure (WBS) [46], controlling scope by dealing with scope changes such as feature break down structure and Feature Transition Charts (FTC) [47], scope verification using WBS [46], [48], and quantifying scope using the given requirements such as Function Points (FP) and Function Size Measurement (FSM) [49], [50]. None of these tools or methods help in defining the scope, although they do help with managing the scope that is already defined. However, among these, is a method called Software Project Scope Rating Index (SPSRI), developed for the software industry in our previous work [51]. SPSRI is the most comprehensive method for defining and evaluating the scope definition of software projects. It provides a list of aspects/elements to assess the completeness and quality of software project scope definition. It uses 45 different aspects/elements of software scope definition in a form of weighted checklist to provide guidance. These aspects were identified through a systematic literature review from 1994 to 2016 and were grouped into 11 categories and further grouped into three main sections (shown in Figure 1 in Appendix-A). Aspects were further defined using the detailed description to generate their clear understanding. Moreover, the aspects were validated through a survey of 20 companies that were mainly engaged in software development projects. SPSRI allows practitioners to define better project scope by evaluating its quality. The list of aspects not only helps to assess overall quality but can also help to identify areas/aspects of scope that need attention or further analysis.

FIGURE 1.

SPSRI sections, categories, and elements.

Although SPSRI has been proved to be usable and useful when validated, an assessment of the elements list is still lacking because of the complex characteristics of each element. The elements list can be further examined to have a better understanding of the influencing dynamics of the elements, i.e., the degree of driver-dependence among the elements. This sort of information can be used by the project managers to identify the elements they should concentrate on when defining the scope of the software projects. Moreover, the elements could also be evaluated in terms of contribution to the project scope completeness and quality. Even though all scope elements are significant for planning the project, some have low contribution; this is because these elements may be defined briefly at the planning stage, and then in more detail at later stages of the project’s development cycle. It is further noted that the most difficult aspect of developing a software project is precisely deciding what to build, and if done incorrectly cripples the development and the project outcomes. This repeatedly acknowledged observation still holds today [16]. Furthermore, the literature lacks research on software project scope elements interrelationships and influencing dynamics. Therefore, this calls for a wise investigation of the elements. An attempt towards building a framework of scope elements will provide a holistic view to better understand the dynamics of the elements. Thus, there is a need to comprehend the software practitioner’s views on the interrelationships among elements which can help improve the scope definition process.

Therefore, based on the above-mentioned research gap, in the present study, we attempt to extend our previous work by developing an ISM model that can serve as a framework for classifying the scope elements in the context of their interdependency. In addition, DEMATEL has been used to analyze and categorize the elements into cause-and-effect groups. The aim is to recognize and scrutinize the interrelationships among the software project scope definition elements. The problem undertaken in this study is of the multi-criteria decision type, hence a combined Interpretive Structural Modeling (ISM) and Decision-Making Trial and Evaluation Laboratory (DEMATEL) approach is used. ISM-DEMATEL seems to be an appropriate methodology because of the similarities in both such as causal relationships can be expressed easily using the driving and dependence power in the ISM and the prominence and relation value in DEMATEL. This study draws on the literature of software project scope elements, ISM-DEMATEL for exploring the relationships between elements using expert knowledge and identifying the elements that should be focused on more for achieving a high-quality scope definition. The purpose of this research study is to develop a framework of scope definition elements based on the following objectives:

• to review the elements from the perspective of their interdependency and influence on each other

• to derive interrelationships among the elements

• to classify the elements according to their driving and dependence power, and

• to determine the causal and effect relationships of the elements

The main contribution of this study is to determine the hierarchical and causal relationships among the scope definition elements by employing the ISM-DEMATEL methodology. The significance of our work is that the knowledge from this study does not only supplement the existing information but also a better understanding of the scope definition elements can be sought because of the proposed relationship model and the causal diagram. This study provides advanced guidelines based on the identification of critical elements that enhance the scope definition process. Furthermore, the insights from the hierarchical framework and cause-and-effect relationships would help project managers and team members to identify the critical elements on which they should focus more when defining the scope of software projects, and the management of the trade-offs between elements thereby, increasing the chances of project success.

The rest of this article is structured around the following sections: Section II reviews the literature for the significant role of scope definition and introduces the ISM and DEMATEL techniques. Section III summarizes the method used for this research to identify the important software scope definition elements through literature and explains how ISM-DEMATEL was applied to the software scope elements. Section IV provides the results of the study, followed by discussion and resulting guidelines for the project managers in section V. Section VI concludes the study and gives an outlook on future work.

SECTION II. Literature Review

This section explores the role of scope definition in project success and introduces ISM and DEMATEL methodologies. Other frameworks using ISM-DEMATEL are also discussed.

A. Role of Scope in Project Success

Scope management is regarded as more important to project success than any of the other individual knowledge areas. A complete and well-defined scope definition, including both project and product scope, prior to project execution, is integral to project success. Project scope plays a central role in the smooth implementation of the project. In the early stages of the project, a lot of effort is expected from the project team in determining and establishing the project scope, as this effort makes a project successful [15], [52]–​[54]. Scope management is strongly linked to other knowledge areas including cost, time, quality, and risk management. Minor variations and ambiguity in project scope can have costly impacts on the cost, time, and quality of the project affecting project success [15]. Project scope proffers the foundation upon which the project is carried out and is vital to the success of the project [4], [16]. Generally, project success or failure can be traceable to a number of factors that include scope, time, and cost [1], [55]. Among these factors, scope definition is the most significant because if the scope definition is vague and there is no effective control of scope, then the project is a failure [4], [18], [19], [21], [56], [57].

It has been reported that software projects are plagued with high failure rates than other industries’ projects [58]–​[62]. Even today, the percentage of successful software projects is too low and a large number of software projects experience outright failure [63]. According to the recent Standish Group’s CHAOS Report [64], 74% of the software projects studied between 2013 to 2017 failed to meet their scope, schedule, and budget. The survey statistics showed that 21% of the software projects failed, often termed aborted or canceled, and 53% were challenged, completed but with time and budget overrun, also with fewer features and functions. Among several causes of software project failures, an inadequate scope is deemed as one of the biggest contributors [4], [9], [16], [17], [32], [35], [57], [65]. It has been recognized that an inadequate or incomplete scope definition at the early stages of the project life cycle is a common source of difficulties in the implementation process [4], [6], [16], [34], [35], [43].

Numerous studies have stressed the role of scope definition and have shown its correlation to project success [4], [9], [16], [66]. Researchers have realized that defining project scope is an essential practice that processes the projects for execution [4], [9], [15], [67]. Properly defined scope helps in completing the project successfully within time, cost, and the required quality [6], [15]. Moreover, the project scope is considered critical and serves as the basis of every decision [68]. Researchers believe that the scope definition of a project should be made clear at the planning phase and understood by all the stakeholders, involved in important decisions of the project [4], [9], [12]. The development of a high-quality scope is considered as one of the essential practices for achieving better project outcomes [4], [7]. Therefore, it is worth noting that as a well-defined scope plays a critical role in project success, and an inadequate scope definition negatively affects it.

B. Existing Models/Frameworks Using Interpretive Structural Modeling (ISM) and Decision-Making Trial and Evaluation Laboratory (DEMATEL)

ISM is a mathematically derived methodology for recognizing and summarizing variables relationships, which are used to define or observe a problem or an issue. In ISM methodology, expert judgment is used for variables interdependences decisions, therefore it is interpretive in nature [69]. ISM process transforms a set of distinct directly and indirectly related variables into a comprehensive model. The model represents the interdependencies among the variables emphasizing potential influences they may have on each other. This approach is intended mainly as a group process, but can also be used individually [70]. Like ISM, DEMATEL is another well-established MCDM technique for identifying interrelationships amongst various factors or elements. It provides a cause-and-effect diagram which effectively demonstrates the relationships between the variables/factors. In MCDM problems, DEMATEL aids in obtaining the direct and indirect influences amongst the criteria using the group knowledge [71]. ISM and DEMATEL are complementing and powerful structural modeling techniques and deemed superior to other interpretive and decision modeling techniques [72], [73]. Integrated ISM-DEMATEL has been successfully utilized in various contexts and in various fields to deal with decision-making problems [72], [74]–​[76]. However, limited use of ISM-DEMATEL combination has been undertaken by studies in the software engineering domain, therefore studies using these methodologies separately are discussed.

Many studies show the application of the ISM approach in different industries to classify the interrelationships between variables and to highlight the potential influences among these variables using a digraph model or a framework [77]. ISM has been used in many management-related domains for models/frameworks development [78]–​[80]. Literature mentions the use of the ISM approach for software projects as well to discuss how different factors correlate with each other and discover the important factors. ISM has been applied to present a framework to explore the relationships between the risk factors of software projects in public organizations [70]. A risk structure model to identify the risk factors of software projects in e-business has also been presented using ISM [81]. Hughes et al. [82] used ISM and presented a framework to identify the interdependencies and influence of success factors of information system projects. Another study by Hughes et al. [77] has used this approach to present a framework that provides insights into the relationships between the information system project failure factors. Another study was done by Rabani and Talebbeydokhti [83] provided the model of success factors of IT projects using ISM methodology. Chang et al. [84] used ISM to identify the interactive causal relationships between agile factors. Sharma et al. [85] incorporated the ISM approach to establish a model to classify the attributes of agile development methodology. Jain et al. [86] used ISM to present a framework that models and measures agile quality attributes so that practitioners can concentrate their efforts on the most critical attributes and thus achieve higher quality. Qu et al. [87] used the ISM approach to construct a model to recognize potential relationships among risk factors of software projects. Bajwa et al. [88] used this approach to construct a model to extract and present relationships among agile development methodology adoption barriers. Another study used the ISM methodology to develop a hierarchical model for analyzing and modeling software process improvement enablers in software SMEs [89].

Tsai et al. [90] combined Analytical Network Process (ANP), DEMATEL, and zero-one goal programming (ZOGP) for a sourcing decision about in-house IT functions or contracting to a third-party provider. Fan et al. [91] used the extended DEMATEL method to identify IT outsourcing risk factors. Another study combined fuzzy DEMATEL with adaptive Neuro-fuzzy inference system-based multi-criteria decision making (ANFIS MCDM) and intuitionistic fuzzy-based TODIM (IF-TODIM) approaches for better assessment of software project risks [92]. Asad et al. [93] used a Grey-based DEMATEL method to study and model the flexibility capabilities in an IT-based supply chain. Chen et al. [94], combined the DEMATEL and ANP to investigate the relationships among project management, project risks, and IT organizational performance. Another study used DEMATEL with Multi-Attribute Utility Theory (MAUT) to analyze the upgradations aspects of software [95]. A study integrated fuzzy DEMATEL and fuzzy TOPSIS approaches to assess the global software development risk factors [76]. To make the web application design more sustainable and secure, Agrawal et al. [96] have integrated Fuzzy Analytic Hierarchy Process (Fuzzy AHP) and Fuzzy Technique for Order of Preference by Similarity to Ideal Solution (Fuzzy TOPSIS) to propose an assessment framework for assessing the sustainable-security of web applications with a focus on design perception. Another study by Agrawal et al. [97] used a hybrid integrated Fuzzy Analytical Hierarchy Process-Technique for Order of Preference by Similarity to Ideal Solution (Fuzzy AHP-TOPSIS) method to evaluate various information security factors of healthcare web applications. Al-Zahrani [98] combined Analytic Network Method (ANP), Fuzzy Sets (FS), and Technique for Order of Preference by Similarity to Ideal Solution (TOPSIS) to test the usability-security of healthcare software. Kumar et al. [99] proposed the measuring methodology using Fuzzy AHP-TOPSIS (Analytic Hierarchy Process-Technique for Order of Preference by Similarity to Ideal Solution) to evaluate the usability-security of web applications. Further, the most prioritized attribute contributing to building usable-security of the web applications is identified in the study. Another study by Kumar et al. [100] used a hybrid approach of Hesitant Fuzzy (HF) sets, Analytic Hierarchy Process (AHP) and, Technique for Order of Preference by Similarity to Ideal Solution (TOPSIS) techniques to estimate the security-durability of web applications. To estimate the usability along with the security of the software, in another study, Kumar et al. [101] proposed a hybrid model using Hierarchy Process (AHP), Hesitant Fuzzy (HF) sets, and Technique for Order of Preference by Similarity to Ideal Solution (TOPSIS) techniques. A study by Alenezi et al. [102] used the hybrid method of Fuzzy AHP-TOPSIS (Analytic Hierarchy Process-Technique for Order Preference by Similarity Ideal Solution) to present a prioritization framework for assessing the security of a software in a tactics perspective. In the healthcare sector, fuzzy-AHP has been utilized, which identified blockchain technique as the most prioritized technique for better data integrity management [103]. A study also used an integrated fuzzy-ANP-TOPSIS method for selecting the most appropriate blockchain model for maintaining breach-free Electronic Healthcare Record (EHR) systems [104].

Most of the above-mentioned studies have utilized ISM or DEMATEL methodology or have combined these with other MCDM techniques to provide insights on the success, failure, outsourcing factors, and risk factors of software projects. However, this present study is different in that it is one of the first that focuses on the scope definition elements of software projects and employs ISM and DEMATEL to recognize the hierarchical and causal relationships among these elements to enhance the scope definition process.

SECTION III. Research Method

The purpose of this research is to extend our prior research to develop a hierarchical framework of scope definition elements and to distinguish cause and effect elements by 1) identifying the software projects scope definition aspects from 2016 to 2020, 2) deriving interrelationships among the aspects, 3) classifying the aspects according to their influencing and dependence degree, 4) determining the intensity of cause-and-effect relationships among the elements. For this, a combination of the ISM and DEMATEL methods were utilized. The reasons these two methods were combined for this study are that they have similarities such that they are capable of explaining complex relationships between the elements considered in decision making. Secondly, the cause-and-effect relationship can easily be revealed through this combination using driving and dependence power in the ISM and the prominence/relation value in DEMATEL. Thirdly, ISM is a macro-oriented technique whereas DEMATEL balances this with a micro-oriented focus, which helps in understanding and visualizing the level of importance of considered elements through well-described diagrams; hierarchical diagram in ISM and causal diagram in DEMATEL [71].

ISM and DEMATEL use experts’ opinions as a base for exhibiting the relationships among the elements therefore, this study seeks inputs from two separate expert groups. An expert group of 8 individuals (5 software development industry professionals and 3 academics) was consulted at the initial stage as an input for the ISM methodology to explore the contextual relationships among the elements. Increasing the number of experts could lead to greater stability and reliability of the results of the proposed method. Therefore, DEMATEL methodology was applied using the views of the second group comprising of 7 experts (4 from the software development industry and 3 from academia). The profiles of experts can be seen in Table 3. This expert group (second of the two groups) was also used for the purpose of the ISM framework result validation and identification of cause-and-effect relationships among the elements. The industry experts considered for this study have several years of work experience in software development projects. Similarly, academics are from the discipline of software engineering. To improve the validity and reliability of the research and to evaluate the findings, data triangulation and investigator triangulation were used in this research. Data from academics and software development industry experts was amassed to give this research the perspectives of those who study the phenomenon and who deal with the issues. Moreover, investigator triangulation with two researchers was used to interpret and analyze the qualitative data at each stage of the research.

TABLE 1 Primary Search Results

TABLE 2 Scope Definition Aspects/Elements

TABLE 3 Profile of Experts

The steps of the research are shown in Figure 2. Details of the steps are mentioned in the upcoming headings.

FIGURE 2.

Research steps.

A. Systematic Literature Review (SLR) for Identification of Aspects/Elements

In previous research, a systematic literature review was conducted from 1994 to 2016 to identify the elements of the software project scope definition (see Figure 1 in Appendix-A). The review protocol was developed by taking into account the guidelines from [105], which are commonly used in software engineering domain [106]. The reader is referred to [51] for more details on software project scope elements identification from literature. In this present research, we decided to extend the previous SLR to add new recent studies from 2016 to 2020 for elements identification. In this present study, a temporal update of the SLR has been performed without any major changes to the original review protocol [107].

1) Research Questions and Search Strings

The primary objective of this review was to identify the scope definition aspects of software projects from 2016 to 2020. Since we had already reviewed the literature from 1994 to 2016, therefore this review was guided by the research questions and the search terms used in the previous study. The search terms/strings used to search relevant studies are as follows.

(Scope OR scope management OR project scope OR product scope OR software scope OR scoping OR requirements scoping OR scope determination OR scope definition)

AND

(Scope creep OR de-scop* OR over-scop* OR scope issue* OR scope failure)

AND

(Cause* OR root cause* OR reason* OR problem*)

AND

(Effect* OR consequence*)

AND

(Technique* OR method*)

The search term has been adjusted according to the constraints imposed by literature repositories. For example, for the electronic data sources where search string was not accepted as it is, one search term was picked from each of the AND options, and was applied repeatedly, for example: (Scope AND Scope creep AND Cause AND Effect AND Technique).

2) Data Sources

Following electronic data sources were selected to collect relevant literature: IEEE Xplore, Elseviers Science Direct, ACM Digital Library, Springer, and Google Scholar. All the studies, relevant to the objective of this review, were accumulated based on their titles, abstracts, and keywords. Studies included journal papers, conference proceedings, and book chapters.

3) Search Process

The search process consists of two phases: 1) primary search and 2) secondary search. In the primary search phase, the selected literature repositories were searched comprehensively for the relevant studies using the search terms and strings. From the primary search phase, a total of 578 papers were gathered initially as prospective papers. Table 1. presents the results of the primary search. All research papers were then scrutinized based on their titles, abstracts, and keywords. Duplicate papers were eliminated. This phase resulted in the formation of the primary list of papers. Primary list papers were then passed on to the secondary search phase. In the secondary search phase, referenced work from primary list papers was searched in the same electronic data sources. Relevant papers were selected by studying their titles, abstracts, and keywords. This phase resulted in some more papers; a secondary list, that was added to the primary list of papers.

4) Study Selection

Following three steps were used for the paper selection: (1) an initial set of 578 studies was filtered out first; (2) potential studies were identified out of these; and (3) quality assessment of the potential studies. In the first step, the initial set of 578 studies was reduced to 381 on the basis of their titles. Then, based on the abstracts, these 381 studies were further reduced to 96. In the second step, full-text filtration was performed by applying inclusion/exclusion criteria that are mentioned in Appendix-B. This step resulted in 73 potential studies.

5) Scrutiny and Quality Assessment

Paper titles were examined, and the contents were briefly explored to find the most relevant ones. Papers that did not express the subject area or study emphasis were disqualified. In addition to that, papers available in English only were included. Relevant papers published between 2016 and 2020 were selected. In the case of duplicates, the most recent, comprehensive, and improved study was included. After scrutiny, 41 papers were selected for quality assessment. All papers were assessed against quality criteria shown in Appendix-C using a scoring method. The outcome of this stage was 16 papers.

6) Data Extraction and Review Findings

In the data extraction phase, the selected studies were explored in detail to obtain adequate aspects of the software project scope definition. The identified aspects/elements are listed in Table 2 below.

B. Comparing and Updating Aspects/Elements

From the selected 16 papers, aspects/elements that are needed in the scope definition of software projects to measure its completeness and quality were identified (shown in Table 1). All these new identified aspects/elements from 2016 to 2020 studies were compared with the previous aspects/elements. It was found out that all the aspects/elements are related. Elements descriptions were also checked for comparison purposes and no new aspects/elements were found. For example, Lampa et al. [15] have highlighted the aspects/elements: “clear and accurate requirements”, “stakeholders’ needs”, “user involvement”, “budget”, “schedule”, “constraints” for the scope definition of software projects. Since all these aspects are already in the list of previous elements in the following categories: “Project Requirements”, “People” and “Project Estimating and Scheduling”. Therefore, no new aspects/elements were added to the list for the ISM-DEMATEL approach. Furthermore, it is worth noticing here, that “project mission (clear and realistic goals/requirements)”, “stakeholder expectations”, “capable team members”, “project schedule and cost estimates” have the highest ranks in SPSRI, and these aspects have also been accentuated in the newly selected 16 studies in constituting a complete scope definition (see Figure 3).

FIGURE 3.

Software project scope definition aspects/elements with their frequencies.

C. Framework Development Using ISM Process–Interrelationships of Elements

Using ISM methodology, this study aims to build a framework of software scope elements to better understand their dynamics and help software practitioners to act proactively and focus on potential elements that may help to achieve a better scope definition for software projects. The ISM methodology suggests that expert perspectives based on various techniques such as brainstorming, structured interviews, Delphi method, or group techniques should be used for developing the contextual relationships among the elements. For this reason, semi-structured interviews and focus group discussions were done with group I which consisted of eight experts, three from academia (from a local university) and five from the software industry (3 from a Sweden based company that specializes in software development and 2 from a local software house based in Islamabad Pakistan). The profiles of these experts are presented in Table 3. Different steps of the ISM methodology are discussed in the upcoming headings.

1) Structural Self-Interaction Matrix

To gather the data about the relationships among aspects/elements a questionnaire (where an empty SSIM was set out for experts’ inputs) was designed which was shared with the experts in semi-structured interviews followed by a focus group discussion to analyze and combine the answers. During the semi-structured interviews, the researcher presented the objective of the study and provided the descriptions of the scope elements to experts for clarifying the meaning of each element. After that, the participants were asked to identify all pairwise relationships between the elements. For investigating the relationships, a contextual relationship of “leads to” was chosen as the focus. This denotes that participants were asked to recognize to what extent one element leads to another, using the SSIM to collect this data.

Four symbols: V, A, X, O are used to denote the type of the relationship that exists between the two elements (i, j) under consideration.

V: means element i leads to element j (element i will influence element j)

A: means element j leads to element i (element i will be influenced by element j)

X: represents a bidirectional relationship (elements i and j will be influenced by each other)

O: no relation between the elements

Separate written opinions of participants were taken, to evade any impact one expert may have on another. In the next step, the answers were analyzed, combined, and discoursed with experts in a focus group discussion to attain a final matrix (see Figure 4) representing the consensus of the experts on their decisions. The following statements clarify the way symbols are used in the SSIM:

• According to experts’ opinion, element e₁ (future expansions) and elements: e₄₃ (key deliverables), e₄₄ (deliverables dates) and e₄₅ (client acceptance) are unrelated; therefore, the relationship is denoted by O in SSIM

• Element e₇ (project mission) will help achieve the element e₄₃ (key deliverables), therefore, the relationship is denoted by V in SSIM

• Element e₈ (stakeholder expectations) will influence the element e₁ (future expansions); thus, the relationship is represented by A in SSIM

• Element e₇ (project mission) and element e₈ (stakeholder expectations) are related to each other and hence the relationship is an X in SSIM

FIGURE 4.

SSIM showing the interrelationships among the elements.

2) Reachability Matrix

In this step, SSIM was transformed into the Initial Reachability Matrix (IRM) and Final Reachability Matrix (FRM). For IRM, the notations in SSIM are converted to binary format pursuant to the following rules:

• every (i, j) entry in SSIM as “V” becomes 1 for (i, j) and 0 for (j, i) pair

• every (i, j) entry in SSIM as “A” becomes 0 for (i, j) and 1 for (j, i) pair

• every (i, j) entry in SSIM as “X” becomes 1 for (i, j) and for (j, i) pair as well

• every (i, j) entry in SSIM as “O” means both the (i, j) and (j, i) entries become 0

Using these rules, IRM was created as shown in Figure 5. The next Figure 6 shows the FRM, which was obtained after incorporating the property of transitivity. Here driving and dependence power of elements was also calculated for MICMAC analysis (discussed in section IV and V).

FIGURE 5.

Initial Reachability Matrix (IRM).

FIGURE 6.

Final Reachability Matrix (FRM) with driving and dependence power of elements.

3) Levels Partitioning

After the completion of FRM, the reachability and antecedent sets of the elements were developed. The reachability set for a particular element includes the element itself together with other elements that it will support, whereas the antecedent set consists of the element itself and the other elements which will help in achieving it. Afterward, the intersection of these sets is derived for all the elements. The elements with the same reachability and intersection sets are given the top level in the ISM hierarchy. These top-level elements do not help in achieving the other elements in the hierarchy. After identifying the top-level elements, the next step is to remove them from the rest of the elements. This same process is repeated until the level is defined for all the elements. These levels are used in building the ISM framework for visual depiction of the elements and their interrelationships [69]. This partitioning process in the present case was completed in 12 iterations. Figure 7 in Appendix-D shows the elements along with their reachability, antecedent, intersection sets, and levels.

FIGURE 7.

Level partitioning results of elements.

4) Development of ISM Framework

After the levels partitioning process, the final step of the ISM process is the development of the ISM hierarchical framework. Using the final reachability matrix, an initial digraph was obtained. After removing the transitivity links and adding the levels from Figure 7, this digraph was converted into an ISM hierarchical framework as shown in Figure 8.

FIGURE 8.

ISM hierarchical framework.

D. Causal-Effect Analysis Using DEMATEL

DEMATEL is a mathematical method, suitable for the study of complex causal relationships among the elements. In the multi-criteria decision problem, it helps to obtain direct and indirect influences between criteria. DEMATEL methodology can assist in computing the relationship and strength among the involved elements. Using DEMATEL, elements can be easily distinguished into cause and effect groups [71]. The second part of the study categorizes the software project scope definition elements into cause-and-effect groups. Before this exercise, a group of experts (second of the two groups) was engaged in the ISM model validation to ensure model integrity. This group who took part in the ISM model validation and DEMATEL exercise constituted of seven experts, four of whom were from the software industry (two local software houses based in Islamabad Pakistan) with a broad knowledge of software project development and management and three active academicians in an Islamabad university. The group experts’ profiles have been summarized in Table 3. Following the procedure of the DEMATEL method, the experts were asked to determine the intensity of the influence between the elements through the use of scale and pairwise comparisons using a questionnaire survey and focus group discussions. The steps involved in the DEMATEL methodology are discussed in the upcoming headings.

1) Direct Relation Matrix

In the DEMATEL method, the starting point is direct relation matrix A. This matrix is generated using pairwise comparisons, where the experts estimate the degree of direct influence between the elements. Within A, $\text{a}_{ij}$ is denoted as the influence of the element i on element j, and all principal diagonal elements of A are set to zero. In this first step, to generate A, a questionnaire survey and focus group discussion was undertaken. For each expert, a questionnaire in the form of an n $\times$ n matrix (n equals the number of elements) is designed. A 5-point Likert scale with 1 to 5 influence levels representing “No influence,” “Low influence,” “Equal influence,” “High influence,” and “Very high influence,” respectively, were designed for the pairwise comparisons. Figure 9. shows the average direct relationship matrix A, which is constructed from the aggregation of the arithmetic means of responses given by the seven experts on each pair of comparisons on the DEMATEL survey.

FIGURE 9.

Average direct-relationship matrix A.

2) Normalized Direct Relation Matrix

In this step, the normalization of the direct relation matrix is done. Based on the direct relation matrix A, the normalized direct relation matrix can thus be obtained through the following equations (1) and (2):

$$\begin{align*} Y=&\frac {1}{s}A \tag{1}\\ S=&\max \left \{{\max _{1\leq i \leq n}\sum _{j=1}^{n}\alpha _{tj}, \max _{1\leq j \leq n}\sum _{i=1}^{n}\alpha _{tj}}\right \}\tag{2}\end{align*}$$ The normalized direct relation matrix of elements is shown in Figure 10.

FIGURE 10.

Normalized direct-relation matrix Y.

3) Total Relation Matrix

In step 3 of DEMATEL methodology, the total relation matrix T is computed, using the equation (3), which is shown in Figure 11.

$$\begin{equation*} T=Y(I-Y)^{-1}\quad where \lim _{d\to \infty }=[{0}]_{n\times n}\tag{3}\end{equation*}$$ Here I refer to the identity matrix.

FIGURE 11.

Total relation matrix T.

4) Sum of Row and Columns From Matrix T

In the next step, the summation of rows and columns of the elements were computed. Vectors D and R, are used to represent the sum of rows and sum of columns, respectively in the total relation matrix T. ${\text{D}}_{i}$ (sum of the $\text{i}^{\mathrm {th}}$ row in matrix T) value indicates the total given both direct and indirect effects, that element $i$ has on other elements and ${\text{R}}_{j}$ (sum of the $\text{j}^{\mathrm {th}}$ column in matrix T) signifies the total received both direct and indirect effects, that all other elements have on element j. These values are shown in Table 4.

TABLE 4 Degree of Influence

5) Cause-Effect Diagram

After calculating the D and R vectors, in the next step, (D+R) and (D-R) values were calculated which are tabulated in Table 4. The importance order of elements is obtained through the (D+R) dataset, which represents the “centrality degree” where ($\text{D}_{i} +\text{R}_{j}$ ), wherein j = i, indicates the strength of interrelatedness that an element i has with the other elements. Furthermore, “causality degree” is represented by (D-R), which separates the elements into a cause group and an effect group. If (D-R) comes out to be positive, the element is categorized into the cause group and if a negative value is obtained, the element is placed into the effect group [71]. Figure 12. shows the cause-and-effect relationship diagram of the elements.

FIGURE 12.

Cause and effect diagram for elements.

SECTION IV. Results

This section summarizes the important results obtained from the two analyses. Sub-section C presents the first of the two analyses that used expert group I. Data about the relationships among elements using ISM methodology was gathered using semi-structured interviews and focus group discussions with five software industry and three academic experts. Further, the Cross-Impact Matrix Multiplication Applied to Classification (MICMAC) analysis was adopted to examine the influencing dynamics among the elements. MICMAC is not a formal step in ISM methodology, but an additional step for the visual representation of the driving and dependency power of elements using a structured quadrant separated matrix [69]. Based on the driver-dependence degree of the elements (see Figure 6), the strength of the relationships of elements was examined. After that, the elements were classified into the following four clusters: autonomous, linkage, dependent, and independent presented in Figure 13. Elements with weak driver and dependence power are included in the first cluster (autonomous) of the matrix, such elements are relatively detached and have a few links. Elements that are located within this cluster are: e₁ (future expansions), e₂ (capturing dependency relationships among activities), e₄ (project environment), e₅ (market strategy), e₆ (deployment strategy), e₁₉ (building trust), e₂₆ (capturing corporate knowledge), e₃₃ (operational concepts), e₃₆ (managing politics). In the second cluster (dependent), elements having weak driving, but strong dependence power are included. This cluster includes the elements such as e₄₅ (client acceptance), e₄₂ (setting milestones), e₄₁ (track progress), e₄₀ (control and information mechanisms), e₃₉ (effective change management), e₃₈ (project plan review), e₃₅ (contractual terms and conditions), e₃₀ (alternative solutions). These elements form the top-level in the ISM framework and depend on other lower-level elements. The third cluster (linkage) consists of the elements with strong driver and dependence power. These elements have high influencing dynamics such that any action on these elements will affect others and they will also get easily affected by other elements. The linkage elements are: e₇ (clear requirements and goals), e₈ (stakeholder expectations), e₉ (identifying constraints), e₁₀ (capable team members), e₁₃ (user involvement), e₁₈ (responsibilities and commitments), e₂₁ (project schedule), e₂₂ (resource estimation), e₂₃ (initial cost estimates), e₂₄ (technology), e₂₅ (troubleshooting/testing), e₃₁ (managing uncertainties), e₃₂ (proper equipment/tool), e₃₄ (allocate sufficient resources), e₃₇ (monitoring and feedback), e₄₃ (key deliverables), e₄₄ (deliverables dates). These elements come in the middle of the ISM framework and link the independent and dependent elements. A closer review of linkage cluster highlights two clusters within this cluster; one with high driving power, including elements: e₇ (clear requirements and goals), e₈ (stakeholder expectations), e₁₀ (capable team members), e₁₃ (user involvement), e₂₁ (project schedule), e₂₂ (resource estimation), e₂₃ (initial cost estimates), and the other one with low driving power, having the remaining elements of linkage cluster. Elements having strong driving power but weak dependence power fall into the fourth cluster (independent). The elements e₃ (project strategy/summary), e₁₁ (project manager competence), e₁₂ (communication and coordination), e₁₄ (client consultation), e₁₅ (top management support) e₁₆ (training), e₁₇ (project authority), e₂₀ (project finances), e₂₇ (company’s strategic intent), e₂₈ (organizational capabilities), and e₂₉ (business plan/vision) are located within the independent cluster. These elements demonstrate high levels of influence on connected elements at higher levels in the digraph. It may be noted that elements with a very strong driving power called the “primary elements” fall into the linkage and independent clusters.

FIGURE 13.

Elements classification.

Sub-section D, on the other hand, provides the details of the second of the two analysis that used expert group II. From the DEMATEL analysis, it can be seen from Table 4, that eight elements have large influencing degrees including, e₁₁ (project manager competence), e₂₃ (initial cost estimates), e₇ (clear requirements and goals), e₃ (project strategy/summary), e₁₅ (top management support), e₂₁ (project schedule), e₈ (stakeholder expectations), e₂₀ (project finances), e₁₄ (client consultation), e₁₀ (capable team members), e₁₆ (training). Moreover, based on the (D+R) values, the elements: e₂₃ (initial cost estimates), e₇ (clear requirements and goals), e₁₁ (project manager competence), e₂₁ (project schedule), e₈ (stakeholder expectations), e₂₂ (resource estimation), e₃ (project strategy/summary), are the topmost among the important elements. Furthermore, on the basis of (D-R) dataset, it is observed that nineteen elements: e₃ (project strategy/summary), e₇ (clear requirements and goals), e₈ (stakeholder expectations), e₁₀ (capable team members), e₁₁ (project manager competence), e₁₂ (communication and coordination), e₁₃ (user involvement), e₁₄ (client consultation), e₁₅ (top management support), e₁₆ (training), e₁₇ (project authority), e₂₀ (project finances), e₂₁ (project schedule), e₂₃ (initial cost estimates), e₂₄ (technology), e₂₈ (organizational capabilities), e₂₉ (business plan/vision), e₃₃ (operational concepts), e₃₄ (allocate sufficient resources), belong to the cause group. These cause group elements may be understood as independent elements, which have high priority and direct impact on the other elements, indicating that these elements are the most influential ones and should be addressed first to figure out the elements under the effect group. Elements who fell into the effect group having negative (D-R) value include: e₁ (future expansions), e₂ (capturing dependency relationships among activities), e₄ (project environment), e₅ (market strategy), e₆ (deployment strategy), e₉ (identifying constraints), e₁₈ (responsibilities and commitments), e₁₉ (building trust), e₂₂ (resource estimation), e₂₅ (troubleshooting/testing), e₂₆ (capturing corporate knowledge), e₂₇ (company’s strategic intent), e₃₀ (alternative solutions), e₃₁ (managing uncertainties), e₃₂ (proper equipment/tool), e₃₅ (contractual terms and conditions), e₃₆ (managing politics), e₃₇ (monitoring and feedback), e₃₈ (project plan review), e₃₉ (effective change management), e₄₀ (control and information mechanisms), e₄₁ (track progress), e₄₂ (setting milestones), e₄₃ (key deliverables), e₄₄ (deliverables dates), e₄₅ (client acceptance). These elements tend to be easily influenced by the other elements.

SECTION V. Discussions

The present study presents the interrelationships among the software scope definition elements which are modeled using the ISM and DEMATEL methodology. ISM and DEMATEL share some similar characteristics as both investigate the relationships among multiple criteria so analysis of the interdependence of software scope definition elements is carried out with the help of ISM and DEMATEL analysis. The MICMAC analysis and the ISM framework diagrammatically illustrate the strong interdependency among the elements and the possible impact of some elements on others in the framework. The elements in the autonomous cluster are considered important too, but they possess weak interaction in terms of driving and dependence power, such that these elements do not help achieve or derive other elements. Therefore, we can say that these elements such as e₁ (future expansions), e₂ (capturing dependency relationships among activities), e₄ (project environment), e₅ (market strategy), e₆ (deployment strategy), e₁₉ (building trust), e₂₆ (capturing corporate knowledge), e₃₃ (operational concepts), e₃₆ (managing politics) are relatively disconnected with other elements and can be selected as not applicable at the planning stage, as they also have low weights in SPSRI method and can be defined at the later stages of the project. The second cluster includes the elements which are strongly dependent on others, such as e₄₂ (setting milestones) and e₄₅ (client acceptance) are dependent on the requirements and stakeholder expectations of the project and therefore, should be defined after defining the other elements. Furthermore, the improvement of the elements in this cluster depends on other elements, namely e₇ (project mission/clear requirements and goals), e₈ (stakeholder expectations), and so on. The elements: e₃ (project strategy/summary), e₇ (project mission/clear requirements and goals), e₈ (stakeholder expectations), e₁₀ (capable team members), e₁₁ (project manager’s competence), e₁₂ (communication and coordination), e₁₃ (user/client involvement), e₁₄ (client consultation), e₁₅ (top management support), e₂₀ (project finances), e₂₁ (project schedule), e₂₂ (resource estimation), and e₂₃ (initial cost estimates) exhibit maximum driving powers and are at the bottom levels of the ISM framework. The characteristics of these elements are that they have higher weights in the SPSRI method, meaning that they have been mentioned as the critical factors for measuring the completeness and quality of the scope definition of software projects [51]. Moreover, these elements can also be found in the recent literature review studies (see Figure 3) [15], [35], [111], [116], [119]–​[121]. These studies have emphasized these elements for the software project scope definition. This research work extends these findings by identifying the criticality of these elements and their influence on the other elements. Furthermore, the interdependency of these elements suggests that software project managers/developers or organizations need to concentrate on these elements for driving a high-quality scope definition. In literature, element e₇ (project mission/clear and realistic requirements and goals) is cited as the most critical element of the software project scope definition [15], [119]–​[121]. This finding is also supported by this study since this element demonstrates the highest levels of driving and dependence power in MICMAC analysis and ISM framework emphasizing its influence on other elements. This is because when defining the other elements such as project cost estimates or schedule estimates, requirements of the projects are considered. Besides, this element is clustered in the linkage quadrant and also closely associated with other elements, to name a few: e₈ (stakeholder expectations), e₂₁ (project schedule), e₂₂ (resource estimation), and e₂₃ (initial cost estimates), highlighting the significant role that these closely linked elements play in the remaining linkages within the framework. The elements with higher dependency powers located at the top level of the ISM framework such as e₄₂ (setting milestones), e₄₃ (key deliverables), e₄₄ (deliverable dates), and e₄₅ (client acceptance), demonstrate how the interconnected elements below in the framework can influence these elements which include the project requirements as well. The elements in the fourth cluster include e₁₁ (project manager competence), e₁₂ (communication and coordination), e₁₄ (client consultation), e₁₅ (top management support) e₁₆ (training). These elements influence other elements such as project manager competence, communication, and coordination and client consultation will result in better elicitation of the project requirements. Thus, the organizations should focus on these elements as well to improve the scope definition. The primary contributors to scope definition completeness and quality are the elements in the linkage cluster as they have high influencing dynamics and substantially interact with other elements. The results indicate that by enhancing these elements, other elements can also be improved which will help in achieving a better scope definition. Therefore, project managers should define these elements properly in the scope definition at the planning stage of the project development life cycle, recognizing the influence they have on other elements in the framework.

From the DEMATEL analysis, it is observed that, e₃ (project strategy/summary), e₇ (clear requirements and goals), e₈ (stakeholder expectations), e₁₀ (capable team members), e₁₁ (project manager competence), e₁₂ (communication and coordination), e₁₃ (user involvement), e₁₄ (client consultation), e₁₅ (top management support), e₁₆ (training), e₁₇ (project authority), e₂₀ (project finances), e₂₁ (project schedule), e₂₃ (initial cost estimates), e₂₄ (technology), e₂₈ (organizational capabilities), e₂₉ (business plan/vision), e₃₃ (operational concepts), e₃₄ (allocate sufficient resources), come under the cause group and are considered as the most influential elements. Among the cause group elements, element e₁₁ (project manager competence), has the highest value of causality (D-R). Furthermore, it also has the 3^rd highest value of (D+R) and the highest value of influencing degree (D) of 1.77909, confirming that it has the highest influence on the other elements while accepting very little impact. Furthermore, this element has also been recognized as the independent element in the MICMAC analysis with high driving power. Therefore, based on the results of both methods, element e₁₁ can be recognized as the core element. This could be supported by the research of [117], who argued that the project manager’s skills as a scope definition element. Moreover, e₁₅ (top management support) has the second highest (D-R) value and possesses a high (D+R) value, which implies that it has significant importance. The next element in the cause group with a high (D-R) value is e₃ (project strategy/summary) with the fourth-highest value of D as well. It suggests that this element also greatly influence the scope definition. Similarly, based on the MICMAC analysis, these cause group elements are also in the independent cluster having strong driving powers (Figure 13). Although elements e₇, e₈, e₁₀, e₁₃, e₂₁, e₂₃, e₂₄, e₃₄ are classified as linkage elements in ISM analysis, these elements are in the cause group in the case of DEMATEL analysis because of their high influencing values. These facts suggest that the primary elements with high driving powers fall into the linkage and independent clusters in ISM analysis. Element e₃₃ (operational concepts), which is located in the autonomous cluster in MICMAC analysis, is in the cause group. Although its (D-R) value is positive, its influencing degree (D) is not high enough, therefore, we can say that it is an independent element and does not have a notable impact on other elements. Elements in the autonomous cluster have the least strength of the influence on other elements in the DEMATEL analysis. Moreover, the elements with the higher dependency powers in the MICMAC analysis are categorized into the effect group. Among all the effect group elements, e₄₅ (client acceptance) has the least (D-R) score of −0.61745 which means it receives the highest impact. However, its (D+R) value of 1.58665 indicates that it is still important in the software project scope definition. Moreover, all the cause elements can enhance this element, such as well-written requirements will help in driving this element directly. The next element in the effect group is e₄₂ (setting milestone) with a (D-R) of −0.4185. However, owing to its high (D+R) and D values, it is considered important. The element with a (D-R) of −0.41054 and high D and (D+R) values of 0.67998 and 1.770503 respectively signify that it places third in the effect group. Considering the results, one can state that the majority of the results obtained from the ISM and DEMATEL are consistent to some extent. Therefore, a very similar interpretation to that used in the ISM is applied in DEMATEL; elements from the cause group are of great importance for the software project scope definition and should be addressed at an early stage and more carefully by the project managers as these elements might be treated as the origin of all the other effect group elements. Further, effect group elements are significantly driven by constructing efforts on the cause group elements, thus for a high-quality scope definition, cause group elements should be tackled on a high priority basis.

This study has some implications for project managers. This research offers a base to extend the understanding of important software project scope definition elements. Hierarchic and cause-effect structures of the elements were clarified based on structural modeling methodologies. First, a comprehensive understanding of the relationships among the elements was revealed using the ISM methodology. Then, DEMATEL was employed to quantitatively calculate the importance, intensity, and effect in the interaction among the elements. The above discussions highlight the critical elements that can enhance the scope definition of software projects. The results of the combined ISM and DEMATEL approach used in this work are very relevant and useful for the managers. The findings of the study offer project managers and team members a more focused approach to segregate the important elements in order to achieve a high-quality scope definition. The important elements having higher driving power are required to be treated at an early stage, so as there may be few other dependent elements influenced by them. These elements include: e₂₃ (initial cost estimates), e₇ (project mission/clear requirements and goals), e₁₁ (project manager’s competence), e₂₁ (project schedule), e₈ (stakeholder expectations), e₂₂ (resource estimation), e₂₀ (project finances), e₃ (project strategy/summary), e₁₆ (training), and e₁₀ (capable team members). These important elements are identified based on their higher degree of centrality (Table 4), and they are also closely related to other elements. Furthermore, the remaining cause group elements such as e₁₂ (communication and coordination), e₁₃ (user/client involvement), e₁₄ (client consultation), e₁₅ (top management support), e₂₈ (organizational capabilities), e₂₉ (business plan/vision) which also have high driving power and high influencing degree are also significant as they may help to attain other elements appearing at the top and middle of the ISM model. These elements require continuous attention from the project managers, therefore paying attention to these elements will facilitate the achievement of a high-quality scope definition.

SECTION VI. Conclusion and Future Work

To formulate the scope definition of software projects, elements that constitute a complete scope definition were previously identified and ranked. However, it is important for practitioners to understand the characteristics and interrelationships of these elements. Considering the highly important role of scope definition in the success of software projects, this study has extended the existing research and understanding of the scope definition elements. Based on the combination of the structural modeling methodologies ISM and DEMATEL, a framework has been proposed, to analyze the relationship structure and identify the most influencing elements. ISM methodology was employed to explore the interrelationships and hierarchy among the elements that yielded further insights into the interdependency of the elements. Further, the MICMAC analysis helped in examining the influencing dynamics of the elements, which also offered useful insights into the relative significance of the elements and their interdependencies (autonomous, dependent, linkage, and independent). Moreover, the DEMATEL analysis output gave a further detailed depiction of the cause-effect relationship of the elements, including the assignment of numerical values which corresponded to the strength each element exerted on the others and to the group of elements as a whole.

The findings of this study demonstrate the important interconnectedness of several scope definition elements. The results call attention to the elements with maximum driving power to be considered properly when defining the scope of software projects as these elements influence many other elements in the framework. The most influential elements with high driving power in the proposed framework are: e₇ (project mission/clear requirements and goals), e₈ (stakeholder expectations), e₁₀ (capable team members), e₁₁ (project manager’s competence), e₁₂ (communication and coordination), e₁₃ (user/client involvement), e₁₄ (client consultation), e₁₅ (top management support), e₂₀ (project finances), e₂₁ (project schedule). These elements help drive other elements and are also dependent on each other, such as project requirements help in driving the project cost and schedule estimate, but these three factors are connected in such a way that any change to one of them has an effect on other as well. Moreover, the DEMATEL approach uncovered the influenced and influential interactions (causal interactions) among the elements which corresponded to nineteen cause group elements. The combination of ISM and DEMATEL proved suitable to better understand elements’ structure and identify the most influential elements, which corresponded to the following elements: e₂₃ (initial cost estimates), e₇ (project mission/clear requirements and goals), e₁₁ (project manager’s competence), e₂₁ (project schedule), e₈ (stakeholder expectations), e₂₂ (resource estimation), e₂₀ (project finances), e₃ (project strategy/summary), e₁₆ (training), and e₁₀ (capable team members). Therefore, this interrelationship analysis of elements revealed the most governing elements and have provided a precise way of identifying the significant elements which should be considered by the project managers and team members for defining the scope of software projects. These elements with high driving power and high influencing degree should receive extra attention for defining high-quality project scope.

This study has contributed to the literature by proposing a relationship model (hierarchical and cause-effect relationship) of the scope definition elements to guide the practitioners with a deeper understanding of these elements when defining the scope of projects. By adopting ISM and DEMATEL methodology, this research study provided new insights over the previous research in recognizing the significance and influence of specific elements and how these contribute to scope definition. Advanced guidelines based on the critical elements are provided for software practitioners to foster improvements in achieving a high-quality scope definition. The proposed framework can serve as a step forward towards improving the success rate of software projects by defining better scope statements at the planning stage. However, this study has some limitations as experts’ opinions have been sought to recognize the driving and dependence power of the elements and for the development of the cause-effect diagram. Therefore, the developed framework is dependent on these opinions and has some element of bias. Moreover, the number of experts was limited to fifteen, which could have also caused bias in the study due to their specific knowledge and experience. Thus, expanding the number of experts in the future study is also suggested. Another limitation of this research is the exclusion of some digital repositories e.g., Scopus during the systematic literature review. However, we have selected well-known scientific repositories i.e., IEEE Xplore, Springer, Elsevier Science Direct, and ACM Digital Library. An immense number of good quality studies are provided by these repositories. Moreover, to not miss any relevant studies, backward snowballing technique has also been applied by tracking the references of the selected studies. Furthermore, software project scope definition elements have been searched manually and using the SLR from 1994 to 2020 in well-renowned repositories, therefore according to some existing recent SLR studies, the used electronic data sources are sufficient to generalize the results of the study [122]–​[132]. Further, the framework has not been statistically validated therefore, using Structural Equation Modeling (SEM) for statistically validating the framework using a larger number of experts would be fruitful for future research.

Appendix A

See Figure 1.

Appendix B Inclusion/Exclusion Criteria

See Table 5.

TABLE 5 The Same Criteria Used in the Previous Study Were Applied in This Study (Except for the Years)

Appendix C Quality Assessment Criteria and Assessment Table

See Table 6 and 7.

TABLE 6 We Adapted the Previously Used Quality Assessment Criteria and the Scoring Process for This Study

TABLE 7 Based on the Above QA Questions, Studies That Provided Complete Information Were Given 1 Score, 0.5 for Partial Information, and 0 for No Information Against Any Question. The Papers Which Had Greater Than or Equal to 2 Score Were Finally Selected

Appendix D Levels Partitioning

See Figure 7.