Role of software requirements management tools in rework & software project success

TABLE OF CONTENTS

CHAPTER 1
1.1 Introduction
1.2 Problem Statement
1.3 Main Research Questions
1.3.1 Sub Research Questions
1.4 Rationale of Study
1.5 Significance of Study
1.6 Main Objectives of Study
1.6.1 Sub Objectives of Study
1.7 Overview of the Study

CHAPTER 2
2 Literature Review
2.1 Role of Project Planning in Project Success
2.2 Software Testing and Criteria of Project Success
2.3 Role of Changing Requirements, Software Requirements Management & Software Requirements Traceability in Project Success
2.4 Role of Maturity of SDLC Approach and SRS Management in Project Success
2.5 Scope Creep and Rework Role in project Success
2.6 UseofSRMT and Project Success
2.7 Theoretical Framework
2.8 Hypotheses in Sequential Order

CHAPTER 3
3.1 Elements of Research Design
3.1.1Quantitative Analysis
3.1.2 Type of Study
3.1.3 Extent of Researcher Interference
3.1.4 Mode of Observation and Study Setting
3.1.5 Time Schedule
3.1.6 Study Population
3.1.7 Unit of Analysis and Sample Design
3.1.8 Data Measuring Instruments
3.1.9 Data Analysis
3.1.10 Measures Observed for Collecting Realistic Data
3.2 Coding of data.
3.3 Pretests
3.3.1 Preliminary Survey
3.3.2 Pilot Study

CHAPTER 4
4.1 Introducing Variables in Research
4.2 Demographic Analysis
4.2.1 Company wise survey participation
4.2.2 Gender wise survey participation
4.2.3 Projects completion status wise survey participation
4.2.4 Shapiro-Wilk test of normality of data
4.3 Descriptive Analysis
4.3.1 Software Requirements Management
4.3.2 Software Testing
4.3.3 SRS Document Quality
4.3.4 Maturity of SDLC Approach
4.3.5 Software Requirements Traceability
4.3.6 Scope Creep
4.3.7 Project Planning
4.3.8 UseofSRMT
4.3.9 Changing Requirements
4.3.10 Project Success
4.3.11 Rework
4.4 Model Identification
4.5 Model Evaluation and Realibility
4.6 Hypothesis Testing
4.6.1 H1: Factors of rework is negatively related with rework
4.6.2 H2: Factors of rework is positively related with project success
4.6.3H3:UseofSRMT moderated relationship between factors of rework & PS
4.6.4 H4: Rework mediated the relationship between factors of rework & PS
4.6.5 H1.1: UseofSRMT is negatively related with rework & positively with PS
4.6.6 H1.2: Rework is negatively related with Project Success
4.6.7 H1.3: PP is negatively related with rework & positively with PS
4.6.8 H1.4: SRSDQ is negatively related with rework & positively with PS
4.6.9 H1.5: ST is negatively related with rework & positively with PS
4.6.10 H1.6: SRM is negatively related with rework & positively with PS
4.6.11 H1.7: SRT is negatively related with rework & positively with PS
4.6.12 H1.8: MSDLCA is negatively related with rework & positively with PS
4.6.13 H1.9: CR is negatively related with PS & positively with rework
4.6.14 H1.10: SC is negatively related with PS & positively with rework
4.7 Regession Analysis for Project Success
4.7.1 Regression Analysis for Rework
4.8 Moderation
4.8.1 Moderating Role of UseofSRMT between Rework and PS
4.8.2 Moderating Role of UseofSRMT between Factors of Rework and PS
4.8.3 Mediating Role of rework between Factors of Rework and Project Success
4.9 Findings
4.10 Hypothesis Status

CHAPTER 5
5.1 Conclusion
5.2 Contribution of the Study
5.3 Study Challenges
5.4 Limitations
5.5 Future Research

References

Appendix

Cover letter used for the questionnaire

Instruments used for data Collection

The questionnaire used for data collection

LIST OF FIGURES

Figure 2.1 Project Management Success

Figure 2.2: Requirements Management Definition

Figure 2.3: Project Scope Management

Figure 2.4: Major Rework Cause in SDLC

Figure 2.5 Effective RM as a core competency for PS

Figure 2.6: Rework Ratio in SDLC

Figure 2.7: Theoretical Framework Main Diagram

Figure 2.8: Theoretical Framework Detailed Diagram

Figure 3.1: Flow Chart for Data Analysis

Figure 4.2.1 Graphical distribution of company wise participation

Figure 4.2.2 Graphical Distribution of Gender wise survey participation.

Figure 4.2.3 Graphical distribution of project completion status

Figure 4.2.4 Normality of Data

Figure 4.3.1 Graphical distribution of biggest challenge faced during RM

Figure 4.3.1.1 Graphical distribution of Major source of Requirements Gathering

Figures 4.3.1.2 Descriptive statistics of Software Requirements Management

Figures 4.3.2 Descriptive statistics of Software Testing

Figures 4.3.3 Descriptive statistics of SRS Document Quality

Figures 4.3.4 Descriptive statistics of Maturity of SDLC Approach

Figures 4.3.5 Descriptive statistics of Software Requirements Traceability

Figures 4.3.6 Descriptive statistics of Scope Creep

Figures 4.3.7 Descriptive statistics of Project Planning

Figure 4.3.8 How software requirements were documented and communicated

Figure 4.3.8.1 Graphical distribution of SRMT used in SDLC

Figure 4.3.8.2 Graphical distribution for UseofSRMT

Figure 4.3.8.3 Graphical distribution of Rework and UseofSRMT in SDLC

Figures 4.3.9 Graphical distribution of Changing Requirements

Figure 4.3.10.1 Graphical distribution of designation wise survey participation

Figure 4.3.10.2 Cause of Unsuccessful Software Projects

Figure 4.3.10.3 Graphical distribution of Project Success

Figure 4.3.11.1 Graphical distribution of project completion duration

Figure 4.3.11.2 Graphical distribution of rework in SDLC

Figure 4.3.11.3 High Rework & VeryLow UseofSRMT

Figure 4.3.11.4 High Rework & Low UseofSRMT

Figure 4.3.11.5 Rework & Project completion duration

LIST OF TABLES

Table 2.1 Knowledge areas relative importance

Table 2.2: Critical Success Factors

Table 2.3: Rework Categories

Table 2.4: SRMT and Features

Table 3.1 Company wise survey participation

Table 3.2 Coding of data used for survey data collection..

Table 4.1: Research variables under study

Table 4.2.1 Frequency distribution for company wise survey participation

Table 4.2.2 Gender wise survey participation

Table 4.2.3 Project Completion Status

Table 4.3 - Descriptive analysis of study variables

Table 4.3.1 Biggest challenge faced during requirements management

Table 4.3.1.1 Major source of requirements gathering for the project

Table 4.3.1.2 Descriptive statistics of software requirements management

Table 4.3.2 Descriptive statistics of Software Testing

Table 4.3.3 Descriptive statistics of SRS Document Quality

Table 4.3.4 Descriptive statistics of Maturity of SDLC Approach

Table 4.3.5 Descriptive statistics of Software Requirements Traceability

Table 4.3.6 Descriptive statistics of Scope Creep

Table 4.3.7 Descriptive statistics of Project Planning

Table 4.3.8 How software requirements were documented

Table 4.3.8.1 Software Requirements Management Tool used in SDLC

Table 4.3.8.2 Feature of SRMT used for Project Success

Table 4.3.9 Descriptive statistics of Changing Requirements

Table 4.3.10.1 Designation wise survey participation

Table 4.3.10.2 Descriptive statistics of Project Success

Table 4.3.11.1 Project completion duration

Table 4.3.11.2 Descriptive statistics of Rework

Table 4.4 Correlation between Rework and UseofSRMT

Table 4.4.1 Correlation between Rework and Project Success

Table 4.4.2 Correlation between Rework and Project Planning

Table 4.4.3 Correlation between Project Success and Project Planning

Table 4.4.4 Correlation between Rework and SRS Document Quality

Table 4.4.5 Correlation between Project Success and SRS Document Quality

Table 4.4.6 Correlation between Rework and Software Testing

Table 4.4.7 Correlation between Project Success and Software Testing

Table 4.4.8 Correlation between Rework and Software Requirements Management

Table 4.4.9 Correlation between PS and Software Requirements Management

Table 4.4.10 Correlation between Rework and Software Requirements Traceability

Table 4.4.11 Correlation between PS and Software Requirements Traceability

Table 4.4.12 Correlation between Rework and Maturity of Agile SDLC Approach

Table 4.4.13 Correlation between PS and Maturity of Agile SDLC Approach

Table 4.4.14 Correlation between Rework and Changing Requirements

Table 4.4.15 Correlation between PS and Changing Requirements

Table 4.4.16 Correlation between Rework and Scope Creep

Table 4.4.17 Correlation between PS and Scope Creep

Table 4.4.18 Correlation between Project Success and UseofSRMT

Table 4.4.19 Correlation between FactorsofRework and Rework

Table 4.4.20 Correlation between FactorsofRework and Project Success

Table 4.4.21 Correlations

Table 4.5.1 Reliability statistics of the questionnaire

Table 4.5.2 Reliabilities of each individual item of questionnaire

Table 4.6 Multiple Regression Model Summary

Table 4.6.1 Multiple Regression Anova Statistics

Table 4.6.2 Multiple Regression Coefficients Statistics

Table 4.6.3: Multiple Regression Model Summary of rework

Table 4.6.4: Multiple Regression Anova Statistics of rework

Table 4.6.5: Multiple Regression Coefficients Statistics of rework

Table 4.7.1 Moderating Role of UseofSRMT

Table 4.7.2 Model Summary of UseofSRMT as Moderator

Table 4.7.3: Coefficients Summary of UseofSRMT between rework and PS

Table 4.7.4: Collinearity Statistics of UseofSRMT between rework and PS

Table 4.7.5: Moderating Role of UseofSRMT between Factors of Rework & PS

Table 4.7.6: Model Summary of UseofSRMT as Moderator

Table 4.7.7:Coefficients Summary of UseofSRMT between Factors of Rework & PS

Table 4.7.8 Collineariy Statistics of UseofSRMT between Factors of Rework & PS

Table 4.8 Hypothesis Status

Table 5.1 Measuring Instruments and Scales

LIST OF ABBREVIATIONS

1. Software project success (PS)

2. Software requirements management tools (SRMT)

3. Project management (PM)

4. Software development life cycle (SDLC)

5. Requirements Engineering (RE)

6. Software requirements specification (SRS)

7. Project planning (PP)

8. Software requirements management (SRM)

9. Software testing (ST)

10. SRS document quality (SRSDQ)

11. Software requirements traceability (SRT)

12. Maturity of SDLC approach (MSDLCA)

13. Changing requirements (CR)

14. Scope Creep (SC)

15. Project Management Institute (PMI)

16. Corrective Rework (COR)

17. Retrospective Rework (RR)

18. Evolutionary Rework (ER)

19. Using software requirements management tools (UseofSRMT)

CHAPTER 1

1.1 Introduction

Well-structured requirements engineering (RE) process improved overall software productivity (Damian et al, 2005). Project success (PS) is ensured with RE which is a legitimate phase of software development life cycle (SDLC). RE process consisted of requirement definition and software requirements management phases (Hennicker and Koch, 2000). The requirements definition phase leads to software requirements specification (SRS) document. Software requirements management (SRM) process consists of software requirements documentation, changing requirements (CR) management and software requirements traceability (SRT) processes (Gorschek, 2006). Software requirements consistency and completeness was associated with software project success (PS) (Osmundson et al, 2003). A UK based survey found that poor SRM caused 48% of problems in software development life cycle (SDLC) (Hall, Beecham and Rainer, 2002). NASA projects data found that projects which invested more than 10% resources for software requirements management resulted in low project cost and less schedule overruns compared to those projects which invested less effort to requirements management processes and methodologies (Ivy and Kristin, 2001).

Software projects faced rapidly changing software requirements throughout SDLC which caused schedule delays and budget overruns. Sharif et al. (2012) found that rework impact of these changing software requirements was measured on the basis of total number of artifacts effected, priority of change, number of resources required and SDLC phase which required the change. SRM processes controlled changing requirements and software requirements traceability based on SRS document given as an input to SRM process. SRS document helped as an agreement of understanding between clients and project team members. Data showed that SRM defects caused 70 to 85% of rework cost (Gail, 2004).

Post-delivery maintenance work was traced down to poorly described SRS document (Lang and Duggan, 2001). The SRS document contained the functional details, including what the system will do; system expected performance details, reliability and response time of software. SRS document quality was critical for PS (Bokhari, and Tabrez, 2010). SRS grows dynamically throughout SDLC and required a collaborative management effort. Software project teams wanted SRS to be precisely accurate while users expected SRS to be more flexible so that all the changing requirements could be accommodated. Traceable and modifiable SRS was the key to PS (Hofmann and Lehner, 2001).

Failure to define project scope boundaries and rapid requirements changes resulted in an out of control situation. All requirements changes whether small/large outside initially defined scope parameters caused scope creep. Scope creep was one of the important factors in the PS (Lakshmi, Jawahar and Suma, 2014; Agarwal and Rathod, 2006). Project scope defined the objectives and boundaries for what is included or excluded from the project work which will be done to accomplish PS. Effective scope management was key factor in determining PS. The most critical aspect of scope creep was project scope definition (Burke, 2010; Schwalbe, 2011). Software project scope verification was important for scope creep avoidence which needs to be performed thoroughly to avoid rework.

Inadequate software testing (ST) increased rework in SDLC which ultimately caused schedule/budget delays and lead to project failure. Rework showed insufficient testing of the software product and stakeholder’s lack of interest in product features (Fairly and Willshire, 2005). Rework adversely affected PS. Data showed that almost half of software projects effort and resource utilization was hidden in fixing the software defects. The past project performance reported that rework was a major cause of project failure in 40% of software projects (StandishGroup, 1999). Rework cost upraised as software headed towards completion. During the initial stages of project, rework magnitude and the cost associated with fixing bugs, was found comparatively low and manageable as compared to fixing software bugs during final stages of SDLC.

Using software requirements management tools (UseofSRMT) helped in streamlining the communication gap between project stakeholders to a large extent. UseofSRMT helped in reducing rework (Wang et al, 2009). SRMT features like requirements traceability, impact analysis, requirements validation and coverage analysis provided a road map for PS. UseofSRMT facilitated in managing the verifiability/quality of requirements and ensured PS. UseofSRMT helped software project teams in rapid application development to stay competitive and provided fastest access to market. UseofSRMT helped project teams to estimate the requirements change impact on overall PS. UseofSRMT helped in requirements verification and ensured that project team’s does not waste time on the requirements which were not critical for the project stakeholder. UseofSRMT ensured that the requirements were transparently accessible to all the parties. These tools also provided a powerful searching, querying and a filtration mechanism while maintained a complete history of the requirement changing process.

The PS is achieved through effective software requirements management in scope management knowledge area. PS could be seen in terms of completing the project within scope, time, cost, quality, resource and risk constraints (PMI, 2013). Project management ten knowledge areas include integration, scope, time, cost, quality, human resource, communications, risk, procurement and stakeholder management. Project management ten knowledge areas and five process groups (initiating, planning, executing, monitoring and controlling along with closing) provided adequate guidelines for PS. The PS criteria was based on key influencing factors (like clearly defined project objectives, top management support, stakeholder’s involvement and project planning), project’s characteristics (like nature/type of project, product deliverables, project resources constraints) and explicitly defined PS criteria (schedule/budget/scope deadlines) (Antonio et al, 2013).

PS was viewed differently across various stages of the SDLC. Turner and Zolin (2012) viewed PS in terms of project scope completed within schedule/budget constraints and software product delivered in accordance with the agreed SRS document. After software product delivery, PS was visualized in terms of the product actual performance in accordance with predefined functional and nonfunctional specifications in SRS to judge whether the software product provided the intended benefits. At the later stages PS was judged in terms of achieving organizational strategic objectives and goals. Shenhar, Levy and Dvir (1997) stated that PS was time-dependent: As time goes by, it matters less whether the project meets its resource constraints & after project completion the customer’s satisfaction becomes more relevant. Lim and Mohamed (1999) differentiated the PS criteria from PS factors and found that PS criteria was the set of principles and standards by which judgment was made. The PS factors were the set of influences contributing to PS. Lim and Mohamed (1999) classified the micro viewpoint of PS in terms of meeting the triple constraints of scope, time and budget while macro viewpoint of PS was visualized in terms of stakeholder’s satisfaction.

Project plans are useless, but project planning process was crucial for the PS (Blomquist et al, 2010). The initial project planning (PP) was the most prominent factor for PS agreed and reported by 744 surveyed project respondents (Besner and Hobbs, 2011). Time spent on PP activities reduced project risk and increased magnitude of PS (Wang and Gibson, 2008; Dvir, Raz and Shenhar, 2003). PP at the initial stages of the project played an important role in PS.

Inadequate PP eventually caused project failure (Morris, 1998; Thomas et al, 2008). Zwikael (2009) found that among the nine knowledge areas of PMBOK (Project Management Body of Knowledge) 4th edition, scope management knowledge area related to PP was most prominent factor for PS. PMI suggested project managers to perform 47 processes, including 24 PP processes for PS. PP processes consisted of almost 50% of overall PM processes necessary to be performed by the project managers to ensure PS. Based on the above introduction this study identified & included project planning (PP), SRS document quality (SRSDQ), software testing (ST), software requirements management (SRM), software requirements traceability (SRT), maturity of SDLC approach (MSDLCA), changing requirements (CR) & scope creep (SC) as the factors of rework. Literature does not provide adequate guidelines for rework reduction through the UseofSRMT. An empirical research was hence intended to quantify the role of UseofSRMT between factors of rework and PS.

1.2 Problem Statement

Rework adversely affected PS. MicroFocus (2010) depicted that rework was present at all stages of SDLC and the maximum intensity of rework (40-100%) was present during requirements gathering phase. Inadequate SRM and SRT were the major causes of rework in majority of software projects (Ellis, 2009). An empirical research to quantify the moderating role of UseofSRMT between factors of rework and PS was hence intended. This study is aimed to quantify the associations of factors of rework like project planning, SRS documents quality, software testing, software requirements management, software requirements traceability, changing requirements and scope creep with rework and PS. The study will also quantify the mediating role of rework between factors of rework and PS.

1.3 Main Research Questions

Based on literature review the following main research questions are proposed for this study.

1).How factors of rework are related with rework.
2).How factors of rework are related with project success.
3).Whether UseofSRMT moderated relationship between factors of rework & project success.
4).Whether rework mediated the relationship between factors of rework & project success.

1.3.1 Sub Research Questions

Based on literature review the following sub research questions were proposed for this study.

1.1).How project planning impacts rework and project success?
1.2).What is the impact of SRS document quality on rework and project success?
1.3).What is impact of software testing on rework and project success?
1.4).How software requirements management affect rework and project success?
1.5).Whether software requirements traceability is related with rework and project success?
1.6).Whether changing requirements impact rework and project success?
1.7).Whether scope creep impact rework and project success?
1.8).What is the role of UseofSRMT in rework and project success?
1.9).What is the effect of rework on project success?
1.10).Whether rework has some relation with project duration?
1.11).Which type of rework could be avoided?
1.12).What is the ultimate project success criteria in view of project teams?

1.4 Rationale of Study

Rework emerged as the most frequent burning issue in SDLC. Literature showed that major cause of project failure was poor SRM (Zaineb and Manarvi, 2011). IBM (2009) study showed that an internal website for SRM promoted communication among project stakeholders and facilitated team’s cohesiveness. Literature does not provide adequate guidelines for quantifying the critical role of UseofSRMT between factors of rework and PS.

1.5 Significance of Study

The study will hopefully open new horizons by quantifying the role of these factors of rework with rework and PS. The study will analyze various features of software requirements management tools being used in the software industry. The study determines the moderating role of UseofSRMT between factors of rework and PS.

1.6 Main Objectives of Study

Based on the literature review the following main objectives are set for this study,

1).To quantify the underlying association of the factors of rework with rework.
2).To quantify the underlying association of the factors of rework with project success.
3).To quantify moderating role of UseofSRMT between factors of rework & project success.
4). To quantify mediating role of rework between factors of rework & project success.

1.6.1 Sub Objectives of the Study

Based on the literature review the following sub objectives were set for this study,

1.1).To quantify underlying associations of project planning with rework and project success.
1.2). To explore how SRS document quality was associated with rework and project success.
1.3).To find the impact of software testing with rework and project success.
1.4). To identify how software requirements management impact rework and project success.
1.5). To determine software requirements traceability impact on rework and project success.
1.6). To know how a mature SDLC approach effects rework and project success.
1.7). To see how changing requirements effects rework and project success.
1.8). To explore how scope creep was related with rework and project success.
1.9). To quantify the moderating role of UseofSRMT in rework and project success.
1.10). To know common causes of software projects failure in view of project teams.

1.7 Overview of the Study

Chapter one discusses the introduction of the research and its importance in relevance to various factors of rework under study including project planning, SRS document quality, software testing, software requirements management, software requirements traceability, maturity of SDLC approach, changing requirements & scope creep with PS.

Chapter two deals with the past literature and studies specific to all the above factors of rework under study. The literature review will highlighte the associations among these qualitative variables. Chapter three discusses the research methodology adopted for analyzing the data gathered for this study along with the statistical sampling techniques and details of the instruments which were adopted for data collection from the survey respondents. Chapter four confers the statistical analysis accompanied with results and discussion section and was annotated with descriptive statistics and inferential statistics to analyze the associations of factors of rework with project success. Chapter five is annotated with conclusions, limitations and future recommendations.

“Not all successful managers are competent and not all failed managers are incompetent. Luck still plays a part in the success or failure, but luck favors the competent hard working manager”.

(Rule 10 NASA’s hundred rules for Project Managers)

CHAPTER 2 LITERATURE REVIEW

This chapter emphasizes on the relevant literature regarding factors of rework under study and their associations with rework & project success. Literature review will deal with all the factors of rework individually. The next section of this chapter discusses the impact of these factors of rework with rework and PS in light of the past research. The objective of the research is to quantify the moderating role of UseofSRMT between factors of rework and PS. The literature review is stated with detailed theoretical background of each of factors of rework and quantified the associations of these factors with rework and project success.

2.1 Role of Project Planning in Project Success

Efficient use of project management (PM) tools and techniques increased likelihood of PS (Attarzadeh and Ow, 2008). Project management ten knowledge areas and five process groups provided an adequate roadmap for PS. Requirements analysis remained a key process area (KPA) of the scope management knowledge area in planning process group (PMI, 2013, p.61). Triple constraints of budget, scope and time were some of the important factors which directly affected PS. A project completed on schedule, within budget constraints and fulfilling all users required functionality was supposed to be a successful project. Requirements consistency and completeness was linked with PS (Osmundson et al, 2003). Project success was based on the influencing success factors, nature/type of project and explicitly defined PS criteria (Antonio et al, 2013). Some of the influencing factors which determined PS were clearly defined project objectives, top management support, stakeholder’s involvement, initial project planning and project managers who determined PS. Project’s key characteristics which determined PS included project objectives, project deliverables, project constraints and available resources. In most of the cases project‘s evaluation criteria was typically used to meet budget and scope deadlines along with major emphasis on stakeholder satisfaction. Literature showed that key influencing factors, project’s characteristics and PS evaluation were major contributors in project management success as depicted in Figure 2.1.

illustration not visible in this excerpt

Figure 2.1: Project Management Success adopted from (Antonio et al, 2013)

Project plans are made during initial stages of the project and initial project planning (PP) was the most prominent factor for PS agreed and reported by 744 surveyed project respondents (Besner and Hobbs, 2011). Wrong/Unclear direction taken during the planning phase, makes it difficult to mold the project back on track. Too much planning at the initial stages of project was found worthless without starting actual developmental work. Spending huge amount of time/budget on planning was wastage of resources. The time spent in project planning activities increased the magnitude of PS (Wang and Gibson, 2008; Dvir, Raz and Shenhar, 2003). Project planning at the initial stages of the project played an important role in PS. Time spent on initial planning activities reduced project risk and increased PS rate. Inadequate PP eventually caused project failure (Morris, 1998; Thomas et al, 2008). Too much time spent in planning was associated with poor project performance which caused project’s failure.

Extensive amount of project planning caused lack of resources and forced project managers to crash the project in order to meet the schedule/budget constraints. Crashing of a project was a tedious job and caused extensive rework in software projects. Choma and Bhat (2010) suggested that an optimum amount of effort/resources were required to be spent for project planning. Zwikael (2009) found that among the nine knowledge areas of PMBOK (Project Management Body of Knowledge) 4th edition, the scope management knowledge area related to project planning was the most prominent factor for PS in software industry while cost and procurement knowledge areas contributed least as shown in Table 2.1. PMI (2013) suggested project managers to perform 47 processes, including 24 planning processes for PS. Planning processes consisted of almost 50% of overall PM processes. Software practitioners disagreed that too much planning was always better for PS (Boehm, 1996; Collyer and Warren, 2009).

Table 2.1 knowledge areas relative importance adopted from Zwikael (2009)

illustration not visible in this excerpt

The planning activities including requirements definition, scope definition and work break down structure were very important for PS (Shenhar et al, 2002). Clearly defined requirements and well-structured scope definition helped in confronting the scope creep phenomenon and reduced rework. Poorly defined scope and RM caused extensive rework and the projects were unsuccessful. “Project plans are useless, but project planning process is indispensable" for the project success (Blomquist et al, 2010). i.e. detailed planning during the planning phase was critical for PS. PS was related with quality of planning processes rather with the duration of the plans or the resources used for the planning proces.

2.2 Software Testing and Criteria for Project Success

Inadequate testing increased rework in SDLC which ultimately caused schedule/budget delays and in return lead to project failure. Literature showed that low magnitude of rework was a sign of insufficient testing of the software product and stakeholder’s lack of interest in product features (Fairly and Willshire, 2005). PS was normally viewed in terms of meeting/exceeding some predestined objectives of schedule, budget and quality. Various criteria’s were used as a standard approach to judge and measure the PS.

Lim and Mohamed (1999) differentiated the PS criteria from PS factors. They found that PS criterion was the set of principles and standards by which judgment was made from while the PS factors were the set of influences contributing to PS or failure. They also classified micro viewpoint of PS in terms of meeting the triple constraints of scope, time and budget while the macro viewpoint of PS in terms of stakeholder satisfaction. Stakeholder’s interests must be incorporated as long term project success factor. Agarwal and Rathod (2006) defined PS in view of internal stakeholders of project like software project team members and concluded that the project scope completion (composed of the functionality and quality of the final product) was the ultimate PS criteria. Project teams should look for the achievement of long term goals and see whether the project was providing the intended results for which it was built. Stakeholder’s satisfaction level was directly linked with PS. Shenhar et al (2001) found that PS perceptions varied among project stakeholders and suggested four key dimensions of PS based on project efficiency, customer impact, direct impact on business success and the future adequacy of the project.

Davis (2013) found that there was lack of an agreement on PS perceptions among different project stakeholders, including senior management, project team members and others. PS rates and criteria differed depending on project industry and its complexity (Muller and Turner, 2007). PS criteria and objectives should be determined at the start of the project initiation phase. PS perceptions were changed within the project stakeholders. Project manager visualized quality in terms of maintainability, efficiency and effectiveness of a project. While the perception about quality among other team mates was that how much productive the project was? Or how quickly the project was able to solve the problems? Effective end user involvement was a critical factor and minimized the communication gap to achieve PS. Morris and Hough (1987) found that projects which violated, the time and cost estimates were still successful projects based on the nature of the project. Life critical or flood protection projects like the Thames Barrier (UK, London Flood Protection System) required extra time or cost, but still they were successful project since they satisfied the stakeholder’s prime interests.

McLeod et al. (2012) developed a framework for project managers to determine PS and described PS as an emergent, multidimensional and subjective process which was based on various perspectives. Savolainen et al (2012) viewed PS from the supplier’s perspective and identified customer satisfaction, project /customer’s short term and long term success as PS. Thomas et al. (2008) found that measuring PS was a tedious game. There were numerous examples of software projects where the original objectives of the project were not met, but project stakeholders were highly satisfied with the project's outcome and the projects remained successful. There were examples where the project objectives were met, but the client was quite unhappy with the project results and caused project failure. Collyer and warren give the example of Titanic movie, which was originally late, over budget but the project was eventually successful. Projects meeting the stockholders expectations and interests helped in achieving PS. The Sydney Opera House project was completed with a delay of 15 years and a budget overrun of 14 times the original budget, but still it was a successful project and an engineering masterpiece of Sydney (Fodor’s, 1997). PS needs to be visualized beyond the triple constraints of the iron triangle, i.e. time, cost and quality. These factors were worthwhile for PS but project teams were unable to certify that a project was successful even if the project was completed within scheduled and estimated/ budgeted parameters.

Quality factor was just a phenomenon which was changed with the type and nature of the project (Roger, 1999). Budget and schedule estimates were the best guesses used for project teams when they possessed limited information about the project. These estimates were based on the learning’s and experiences from previous project’s knowledge base library. Project teams were reluctant to visualize the project success beyond the cost, time and quality guesses. Project teams looked for smart processes to develop successful products and never looked for smart PS criteria. Project teams tried to meet the two best guesses of time and cost while focused on the quality phenomenon. This was described as “doing something right to meet the milestones of the project”. But it was not the guarantee of PS.

PS needs to be seen as a science of converting stakeholder’s vision, perceptions and philosophy into reality (Turner, 1996). Stakeholder’s interests and satisfaction should be focused as a critical success factor. Projects which fulfilled the iron triangle success criteria were not successful projects until and unless they were productive and meet or exceed stakeholder demands. Project milestones should not be used as a measure of the PS (Williams, 1995). Milestones were set for short term measures and the earned value methods were used to monitor the project progress and ensured that the project was proceeding on the right track. PS criteria also depended on the type of project. Medical and real time projects were more quality focused. Project team members, managers and top management along with customers were important stakeholder’s in determining the PS.

DeLone and McLean (1992) gave six legitimate factors of PS in the context of system quality, information quality, information use, user satisfaction, individual impact and organizational impact while focused on five performance gaps that occurred between inevitable stakeholders like customers, project teams and project outcomes at different phases of the project. Long term benefits should also be included in the PS criteria. (Shenhar, Levy and Dvir, 1997) emphasized that the project teams should “see the big picture. . ., be aware of the results expected . . . and look for long term benefits” and gave four success factors of project efficiency, product’s impact on customers, business success and future measures preparation as critical success factors for PS. Over the past few years, PS rate had kept very low up to 16.2%, while 52.7% of the projects were unsuccessful due to schedule or budget overruns. Various factors contributed to the PS but they could not be specified as PS criteria. PS was normally seen in terms of stakeholder’s satisfaction and meeting the project requirements. Critical factors which contributed to the PS could be seen in Table 2.2.

Table 2.2: Critical Success Factors adopted from (Attarzadeh and Ow, 2008)

illustration not visible in this excerpt

2.3 Role of Changing Requirements, Software Requirements Management and Software Requirements Traceability in Project Success

RM controlled changing requirements and requirements traceability of SRS document given as input to the RM process as depicted in Figure 2.2.

illustration not visible in this excerpt

Figure 2.2: Requirements Management Definition adapted from (Hennicker and Koch, 2000)

Nuseibeh and Easterbrook (2000) found that software requirements traceability was mandatory for SRM in SDLC. Mark (2014) showed that inaccurate requirements gathering was the primary cause in 37% of software project failure during year 2014.

Mark also found that when projects does not meet their original goals and business objectives, poor RM was the primary cause of this failure almost half of the time. A lot of organizations still lacked maturity in SRM process due to lack of availability of the necessary skilled workforce which could perform it properly. The executive management, project sponsors and other project stakeholders were found reluctant in achieving excellence in SRM process. PS could be ensured by capturing valid, reliable, concise, feasible, verifiable, traceable and maintainable requirements in scope management knowledge area (PMI, 2013, p. 61) as shown in Figure 2.3.

illustration not visible in this excerpt

Figure 2.3: Project scope Management adopted from (PMI, 2010, p.61)

Aaron, David and Tricia (2014) found that 5.1% of every dollar spent on software projects was wasted due to poor SRM .The bigger picture found that US$51 million were wasted for every US$1 billion spent on software projects. Aaron, David and Tricia showed that every three out of four organizations reported that poor communication between project stakeholders negatively effected SRM in 75% projects more than any other area, including risk, schedule/budget etc. The effect of poor SRM was worse for low performance organizations (which completed 60% or fewer projects on time, within budget and meeting original goals). Half of the projects were unsuccessful due to poor SRM in low performance organizations.

Data on past project performance report shown in Figure 2.4 showed that the major cause of project failure remained poor SRM (Zaineb and Manarvi, 2011; Standish Group, 1999; Micro Focus, 2010).

illustration not visible in this excerpt

Figure 2.4: Major Rework Cause in SDLC adopted by (Standish Group, 1999; MicroFocus, 2010)

Hall, Beecham and Rainer (2002) found that poor SRM caused 48% of problems in SDLC. Data results showed that it costed 10 cents for every dollar spent in low performance organizations. Data collected from high performance organizations (which achieved 80% or more projects on time, within budget and meeting original goals), clinched that only 11% of the projects remained unsuccessful in meeting their original goals in these organizations. SRM consisted of documentation, change management and traceability (Gorschek, 2006). The waste due to poor SRM remained within bearable limits of just 1 cent for every dollar spent by high performing organizations as compared to 10 cents lost for every dollar spent by low performing organizations due to poor SRM. Many challenges were faced by software teams.

Requirements errors were found as a major source of rework in SDLC. SRM managed constantly changing requirements in SDLC (Shahid, Ibrahim and Mahrin, 2011). High performance organizations stressed on effective SRM as a core competency for PS as depicted in Figure 2.5.

illustration not visible in this excerpt

Figure 2.5 Effective RM as a core competency for PS adopted from (Aaron, David and Tricia, 2014)

Complete and well-structured SRM process was critical for PS (Verner et al, 2005). Poor SRM remained one of the top three critical factors of project failure. RM helped in project team collaboration to harness innovation and reduced rework. Standish Group (2011) reported that lack of SRM lead to project failure. Effective SRM helped software teams in reducing project schedule and budget overruns. Software teams were unhappy in assigning adequate resources for SRM and wasted extra time, money and other resources in bug fixing during the testing phase. A study of software projects in the telecommunications and banking sectors found that successful projects allocated 38.6% of scheduled resources for SRM process while on an average 15.7% of resources and effort was used for SRM (Hofmann and Lehner, 2001). Putting more efforts and resources for SRM process increased the likelihood of PS. NASA projects data found that projects which invested more than 10% resources for SRM resulted in low project cost and less schedule overruns compared to those projects which invested less effort to SRM processes and methodologies (Ivy and Kristin, 2001).

Software projects faced rapidly CR throughout SDLC which caused schedule delays and budget overruns. Sharif et al. (2012) found that rework impact of these CR was measured on the basis of total number of artifacts affected, priority of change, no of resources required and SDLC phase which required the change. Software teams faced lack of SRT, which caused rework in SDLC. The rework effort grow as the requirement changes come late in SDLC. Data showed that SRM defects caused 70- 85% of rework cost (Gail, 2004). Rework cost upraised as software headed towards completion. Chua and Verner (2010) found that the CR required a number of updates since the bugs in software applications were fixed mostly while updating lines of source code. Evolutionary rework changes required insertion of new module /modifications in the functionality of existing module. Estimation of rework effort does not depend on size of the CR rather it depends on the complexity of CR, project size/nature and resource requirements (schedule, budget, technical skills, knowledge and experience) for the rework.

2.4 Role of Maturity of SDLC Approach and SRS Management in Project Success

Post-delivery maintenance work was traced down to poorly described SRS document (Lang and Duggan, 2001). The SRS document contained the functional details, including what the system will do; system expected performance details, reliability, speed and response time of software. SRS document quality was critical for PS (Bokhari and Tabrez, 2010). SRS grow dynamically throughout SDLC and required a collaborative management effort. Software project teams wanted SRS to be precisely accurate while users expected SRS to be more flexible so that all the requirements changes could be accommodated. Traceable, consistent and modifiable SRS was the key to PS (Hofmann and Lehner, 2001). Very few project resources were allocated to RM. A study of 66 projects showed that average team size allocated to RM was only 5-6 members of the total project team (Guinan, Cooprider and Faraj, 1998). Survey data collected from 109 software projects in 25 countries identified three critical PS factors. The critical factors included correct project delivery strategy, SDLC /software engineering approach and teams capability. The three other partially important factors in software project success included good project management process, team’s collaborative working environment and strong customer involvement (Tsun and Dac- Buu, 2007). The study failed to conclude that some literature based prerequisites for software project success like executive management support and sponsor commitment were critical factors for PS.

2.5 Scope Creep and Rework Role in Project Success

Clearly defined requirements and well defined scope helped in confronting the scope creep phenomenon and reduced rework. Poorly defined scope and RM caused extensive rework and projects were unsuccessful. Agarwal and Rathod (2006) concluded that project scope composed of the functionality and quality of the final product was the ultimate PS criteria. Project scope defined the objectives and boundaries for what is included or excluded from the project and work which will be done to accomplish PS. Failure to define project scope boundaries and rapid requirements changes resulted in an out of control situation. All requirements changes whether small/large outside initial defined scope parameters caused scope creep. Lakshmi, Jawahar and Suma (2014) found that scope creep was one of the important factors in the success of critical software applications as compared to non critical software applications. An effective scope creep management strategy was required in both the software domains but more specifically for critical software applications. Scope changes effected project schedule/budget, project quality and proportion of software defects which caused rework.

Effective scope management was key factor in determining PS. The most critical aspect of project scope management was project scope definition (Burke, 2010; Schwalbe, 2011). Software project scope verification was important for scope management and needs to be performed thoroughly to avoid rework and scope creep. Moreover, software scope verification. Well defined scope was crucial in the process of delivering exactly what the customer requested and in minimizing project scope changes to contribute in PS.

Turk (2010) found that scope creep resulted from poorly initially defined requirements / SRS specifications with conflicting needs, wrong assumptions from customers, unwillingness to say no to customer, over delivering/gold plating the scope to please the customer and lack of formal change management process. It was found necessary to formally review the changes requested by the customer and approve or reject them through a change control board (CCB). and getting additional payment for scope changes helped in

Scope creep was reduced by performing a thorough requirements analysis, empowering a formalized CCB through a limited number of people to grant scope changes, associating a cost of scope change, communicating requiremnets change impact analysis / cost benefit analysis with customer, ensuring customers to sign off the scope change documents and UseofSRMT were found critical for scope creep manangement.

Scope creep was a source of customer’s cost creep and revenue generation from project while forcing the client to sign off written contract for paying the additional cost expensis. StandishGroup (2004) chaos reported that over 68% of software projects failed to fully meet customer needs. While over 80% of these projects failed due to scope creep. Uncontrolled changes caused projects failure due to schedule delays, budget overruns, frustration among team memebers and low quality product due to the tendency to accept the new functionality.

Mielke (2002) stated that scope creep costed four times the initial development costs which resulted in deferred benefits / lowered return on investment (ROI), increased maintenance costs and project cancellation. Zimmerman (2000) found that scope changes related to addition of requirements / modifications of existing requirements required to perform requirements analysis, design and development. Even if the project was proceeding effectively to date, new features required additional time, effort and cost.

Rework is the work performed again because it was not properly done for the first time. Software teams wasted the majority of their time and resources in rework. Rework increased as projects progressed in SDLC. The cost associated with rework was very high and it was not only limited to extra wastage of time and money on resources. It caused schedule delays, crushed customer’s confidence, damaged brand image and effected return on investment. Data showed that almost half of the software projects effort and resource utilization was hidden in fixing/correcting the software defects. The past project performance report depicted in Figure 2.4 showed that major cause of project failure in 40% of software projects was rework and among 80% software projects, poor SRM of incomplete/ changing requirements was major factor for project failure. Performing rework during the software development phase caused 200 times more as compared with the rework performed during the requirements analysis phase (Boehm and Papaccio, 1988). Literature described three major types of rework as described in Table 2.3. The retrospective rework (RR) was performed in order to achieve the work intentionally left in previous version of the software product. The corrective rework (COR) was performed in order to fix the critical software bugs. The evolutionary rework (ER) was performed to modify previous version of software’s functionality, structure, behavior/quality (Fairley and Willshire, 2005). Little rework was good while excessive rework indicated problems in RM process, developer’s skills and technology used in product development.

Table 2.3: Rework Categories adopted from (Fairley and Willshire, 2005).

illustration not visible in this excerpt

Rework impact raised exponentially as software progressed to later stages of SDLC.

Literature showed that 40% or more rework in SDLC was present in requirements phase as depicted in Figure 2.6 rework ratio in SDLC phases.

Figure 2.6: Rework Ratio in SDLC adopted from (Micro Focus, 2010, p. 2)

illustration not visible in this excerpt

Fairley and Willshire (2005) found that during a specific reporting period in SDLC 10-20% of rework effort was commonly acceptable. Software projects faced a lot of rework which caused up to 80% of the total work effort (Cross, 2002). Rework reduction boosted productivity and produced high quality software products.

2.6 UseofSRMT and Project Success

High performance organizations recognized

the importance of RM processes and practices for their projects. High performance organizations were found more likely to use a formalized process for the RM of projects as compared to low performance counterparts. UseofSRMT helped in streamlining the communication gap between project stakeholders to a large extent. UseofSRMT helped in tailoring rework (Wang et al, 2009). SRMT features like requirements traceability, impact analysis, requirements validation and coverage analysis provided a road map for PS. UseofSRMT facilitated in managing the verifiability/quality of requirements and ensured PS. The critical features which made SRMT most important, varied with project nature and industry requirements.

Software industry used various SRMT depending on the nature, complexity and the specific needs of software products. SRMT and their features are given in Table 2.4.

Table 2.4: SRMT and Features Adopted from (Bokhari and Tabriz, 2010)

A. Clear visibility of the requirements throughout SDLC to all stakeholders.

B. Dynamically linked requirements with different artifacts.

C. Permanent and secure storage location for requirements management.

D. Live requirements traceability/prioritization/addition/deletion/modification.

E. Requirement change management and upward/downward change impact assessment.

F. Integration with other tools for improved communication.

G. Checklist for requirements quality verification and testing.

H. Collaborative development of the software product.

I. Scalability to facilitate more end users if the project/team size grows.

J. Online repository for project related glossary terms and references.

K. Requirements secure import/export from other tools.

L. Secure system with different privileges for various stakeholders.

illustration not visible in this excerpt

UseofSRMT helped software project teams in rapid application development to stay competitive and provided fastest access to market. Well-structured and properly documented requirements through the UseofSRMT facilitated software requirements traceability which enhanced the productivity of the software projects and reduced rework. Clearly visible requirements through the UseofSRMT improved team’s communication and collaboration. Collaborative RM and traceability through the UseofSRMT reduced rework and increased the chances of PS. The reusability of the requirements data through centralized requirements repository supported project teams to streamline the overall SDLC process. Ellis (2009) found that automated SRM during the initial stages of project life cycle, enhanced chances of PS and reduced project overruns by almost 87%. Software project teams faced rapidly changing requirements throughout the SDLC. These rapidly changing requirements caused schedule delays and budget overruns. Project teams were unable to determine the overall rework impact of these rapid changes in the project. UseofSRMT helped project teams to estimate the requirements change impact on overall PS. UseofSRMT helped in requirements verification and ensured that project teams does not waste time on the requirements which were not critical for the project stakeholder. Putting emphasis on verifiable software requirements ensured that project teams achieve the desired goals. UseofSRMT facilitated in tracking the requirements current completion status. It eventually helped in keeping aware all the project stakeholders about the most up to date status of requirements validation/verification or implementation. IBM (2009) found that using an internal website for SRM promoted communication among project stakeholders and facilitated team’s cohesiveness. Ellis emphasized that UseofSRMT doubled PS rate and reduced project overruns up to 87%. IBM study resulted that UseofSRMT achieved a 75% increase in PS and 69% net reduction in rework cost. UseofSRMT ensured that the requirements were transparently accessible to all the parties. These tools also provided a powerful searching, querying and a filtration mechanism while maintained a complete history of the requirement changing process. UseofSRMT enabled rollback to the previous version of the requirement and allowed the end user’s to reuse the existing content. Most important feature of UseofSRMT was to provide requirements change impact analysis facility which was very effective in determining whether it's viable and feasible to accommodate new requirements in the project and still accomplish the required goals and achieve PS.

2.7 Theoretical Framework

Based on the literature review this study identified project planning, SRS document quality, software requirements management, software requirements traceability, software testing, maturity of SDLC approach, changing requirements and scope creep as factors of rework in Project success. Adaptive, functional and corrective changing requirements caused evolutionary rework (ER), retrospective rework (RR) and corrective rework (COR) due to poor requirements management, poor software requirements traceability and lack of well-structured documentation (Chua and Verner, 2010). Wang et al (2009) found that UseofSRMT helped in tailoring rework. MicroFocus (2010) showed that more than 40% of rework in SDLC was present in requirements gathering phase. IBM (2009) found that automated SRM process increased productivity, streamlined communication among project stakeholders and facilitated team’s cohesiveness. Nuseibeh and Easterbrook (2000) found that SRT was mandatory for SRM. Ellis (2009) stressed that effective SRM during the project life cycle enhanced chances of PS. Turk (2010) found that scope creep resulted from poorly initially defined requirements / SRS specifications with conflicting needs, wrong assumptions from customers, unwillingness to say no to customer, over delivering / gold plating the scope to please the customer and lack of formal change management process. Mielke (2002) stated that scope creep costed four times the initial development costs. This study was aimed to quantify the associations of factors of rework with rework & PS. Theoretical framework Figure 2.7 suggested that UseofSRMT moderated the relationship between rework and PS while rework mediated between factors of rework & PS. Figure 2.8 depicted the factors of rework included in the study along with various rework types.

Figure 2.7: Theoretical Framework Main Diagram

illustration not visible in this excerpt

Figure 2.8: Theoretical Framework Detailed Diagram

illustration not visible in this excerpt

2.8 Hypotheses in Sequential Order:

Based on literature review the following research hypotheses were set for this study,

Main Hypotheses:

H1: Factors of rework is negatively related with rework.

H2: Factors of rework is positively related with project success.

H3:UseofSRMT moderated relationship between factors of rework & project success. H4: Rework mediated the relationship between factors of rework & project success.

Sub Hypotheses:

H1.1: SRM is positively related with project success and negatively with rework.

H1.2: SRT is positively related with project success and negatively with rework.

H1.3:CR is negatively related with project success and positively related with rework. H1.4:UseofSRMT is positively related with project success and negatively with rework.

H1.5: Rework is negatively related with project success.

H1.6: MSDLCA is positively related with project success and negatively with rework. H1.7: PP is positively related with project success and negatively with rework. H1.8: SRSDQ is positively related with project success and negatively with rework. H1.9: ST is positively related with project success and negatively with rework. H1.10: SC is negatively related with project success and positively related with rework.

[...]