# An Integrative Model Linking Risk, Risk Management and Project Performance: Support from Indian Software Projects

Sam Thomas, Bhasi Marath

► To cite this version:

Sam Thomas, Bhasi Marath. An Integrative Model Linking Risk, Risk Management and Project Performance: Support from Indian Software Projects. International Working Conference on Transfer and Diffusion of IT (TDIT), Jun 2013, Bangalore, India. pp.326-342, 10.1007/978-3-642-38862-0_20 hal-01467788

HAL Id: hal-01467788

https://inria.hal.science/hal-01467788

Submitted on 14 Feb 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# An Integrative Model Linking Risk, Risk Management and Project Performance: Support from Indian Software Projects

Sam Thomas¹, Bhasi Marath²

¹School of Management Studies, Cochin University of Science and Technology, Cochin, India.

²School of Management Studies, Cochin University of Science and Technology, Cochin, India

Sam8570@gmail.com, mbhasi@cusat.ac.in

## Abstract

Software development organizations across the globe are concerned about the high rate of project failures. Two constructs which are hypothesized to have significant impact on project outcome are risk and risk management. Risk points to an aspect of a development task, process or environment which, if ignored, tends to adversely affect the project performance. Risk management is defined as the mechanism for identifying, addressing and eliminating software risk items before they become threats to project success. Based on the data collected from 527 software development projects in India, this research develops an integrated model linking these three constructs. Structural Equation Modeling was used to develop and validate the models. The models show how the impact of risk management on project outcome may be mediated by risk.

**Key words:** Risk, Risk management, Project Outcome, Software project in India, Structural Equation Modeling

## 1. Introduction

Research on software project risk and project outcome has attracted attention among academicians and practitioners all over the world. One of the reasons why this topic remains relevant across time is that the failure rate continues to be very high among software projects. The latest “chaos” report (2011) from Standish Group research shows that 66% of projects are either “challenged” or downright failures, leaving 34% of projects to be considered successful. Jørgensen and Moløkken-Østvold (2006) suggest that failure rates for software development projects could be up to 85%. As software companies continue to invest time and resources into the development of software, how software development problems and failures can be minimized continues to be a focus area.

Most of the researchers on software project risk broadly agree on a two-step approach to managing risk: risk assessment and risk control. Risk assessment involves identifying, analyzing and prioritizing the risk factors that are likely to compromise a project's success, and risk control involves acting on each risk factor in order to eliminate or control it. (Boehm, 1991; Charette, 1996; Lyytinen et al., 1998; Wallace et al., 2004, Keil et al., 2008, Wen-Ming Han, 2007). Literature review shows that the past research on software project risk has mainly focused on:

(a) *Risk identification and assessment* (McFarlan, 1981; Barki et al., 1993; Neumann, 1995; Keil et al., 1998; Lyytinen et al., 1998; Ropponen & Lyytinen, 2000; Schmidt et al., 2001; Wallace et al., 2004; Tiwana & Keil, 2004; Cuellar & Gallivan, 2006; Costa et al., 2007)

(b) *Risk management strategies for project performance improvement* (Alter & Ginzberg, 1978; Boehm, 1991; Fairley, 1994; Powell & Klein, 1996; Keil et al., 1998; Barki et al., 2001; Barki & Rivard, 2003; Jiang & Klein, 2004; Iversen et al., 2004; Taylor, 2006; Camprieu et al., 2007; Keil et al., 2008)

(c) *Relationship between risk and risk management* (Kirsch, 1996; Ropponen and Lyytinen, 2000; Jiang et al., 2000; Barki et al., 2001; Addision and Vallabh, 2002)

(d) *Link between risk and project performance* (Nidumolu, 1995; Jiang & Klein, 1999; Na et al., 2004; Wallace et al., 2004; Han & Huang, 2007; Na et al., 2007)

Most of the previous research takes an isolated view of software project risk and risk management strategies. Empirical evidence on the relationship between risk, risk management and project outcome is rare. Arguments are largely based on theory or case studies. Yet, this is an important step for advancing our knowledge on software project risk. Most of the projects will have risk management strategies adopted from the beginning of the project. But risk factors continue to exist in the project. What defines the project success will be the combined impact of the risk factors present and the effectiveness of the risk control strategies adopted. This can be analyzed only through an
integrated study on the linkages among risk, risk management and project outcome. This can help project managers to select the needed implementation strategies to achieve their desired project outcomes.

The past research on software project risk is predominantly reported from the western world. This has been acknowledged as a major limitation of the research in this domain (Ropponen and Lyytinen, 1997; Schmidt et al., 2001; Shan Liu et al., 2009). Whenever research was conducted in emerging economies, particularly where cross-cultural research indicates likely differences in behavior or practices, differences were observed in software development risk factors -Schmidt et al. (1996) in USA, Finland and Hong Kong, Na et al. (2006) in Korea, Mursu (2000) in Nigeria, Mann et al. (2002) in Thailand, Shan Liu et al. (2009) in China and Thomas et al. (2011) in India. Cultural differences can impact work related values and play a significant role in the success or failure of projects (Hofstede, 1980). There is a need for more risk related studies across varying socio-economic contexts to validate the models. Also, previous studies have looked at software projects in all types of companies without focusing on software development with only IT companies.

This research is undertaken with an objective of developing insights into the linkages among risk, risk management and project outcome. Based on the data collected from 527 projects executed within the leading software development companies in India, this paper validates an integrated model linking these constructs using Structural Equation Modeling (SEM). Reliable and validated instruments were used for measuring risk, risk management and project outcome. We begin this article with a brief review of the relevant literature. Next the methodology for collecting and analyzing the data is discussed. Finally, the results of the model testing are reported and the implications of the study are discussed.

## 2. Background

The research focus on three constructs namely risk, risk management and project outcome with respect to software development projects. Previous work related to these studies is briefly reviewed here.

### 2.1. Software project risk

A software project risk points to an aspect of a development task, process or environment, which if ignored tends to increase the likelihood of software project failure (Lyytinen et al., 1993). Such incidents pose danger to the development of a successful project leading to inadequate software operations, software re-work, implementation difficulty, delay or uncertainty (Boehm, 1991). Barki et al. (1993) define software development project risk as the product of the uncertainty surrounding a software development project and the magnitude of potential loss associated with project failure.

The most common method for identifying the presence of risk factors has been the use of checklists. These checklists present a list of all potential risks that might be applicable in a software development project. One of the pioneering studies in this regard is the top 10 risk list of Boehm (1991). Barki et al (1993) tried to produce a more comprehensive list of risk factors based on the data collected from 120 ongoing projects in 75 organizations. Jiang and Klein (2002) supplemented this study through a survey among project managers asking them to rank these risk categories in order of importance. One of the most quoted international studies on software project risk factors was conducted by Schmidt et al. in 1996. Their research developed an extensive list of risk factors through three simultaneous Delphi surveys in three different settings: Hong Kong, Finland and the United States. Keil et al (1998) improved upon their international Delphi study exploring the issue of IT project risk from the user perspective and compared it with risk perceptions of project managers. The study was repeated in China (Shan Liu et al., 2009) and Nigeria (Anja Mursu, 1999). The Software Engineering Institute (SEI)'s Taxonomy-Based Risk Identification Instrument, which contains 194 questions, is probably one of the largest checklists of software development risk factors. Moynihan (1997) through his survey on project managers produced a huge collection (113) of risk related constructs and showed that many of the real world issues are not captured in the Barki list and the SEI list. The work by Ropponen and Lyytinen (1997) contributes to the empirical studies on software development risks. Wallace (1999) developed a valid and reliable measure of software project risk to study risk from a common perspective and to compare findings across studies in a more meaningful manner. Addison (2003) through a Delphi study among expert practitioners identified the most important risks in the development of e-commerce projects. IT implementation risk and its impact on the organization have been stressed by many researchers (Alter, 1979; Chatzoglou et al., 2009; Malhotra et al., 2009).
## 2.2 Software project risk management

Once the risk factors are successfully identified and assessed, the next logical step is to manage the risk (Boehm, 1991). Software project risk management is one mechanism for minimizing project failure (McFarlan, 1981; Boehm, 1991; Barki et. al., 1993). Risk management is concerned with a phased and systematic approach to analyse and control the risks occurring in a specific context (Charette, 1996). Project risk management encompasses both hard skills such as estimating and scheduling tasks, and soft skills, which include motivating and managing team members (Kirsch 1996).

Research on software risk management has primarily focused on crafting guidelines for specific tasks. Risk management strategies use observations from the past; they learn from analogical situations, and they use deductive reasoning to detect risky incidents. Alter and Ginzberg's (1978) focused on problems associated with the organizational acceptance and implementation of the information system. Davis' model (1982) is concerned with selecting procedures that lead to complete and correct information requirements. McFarlan (1982) classified risk resolution techniques into four types, namely External integration, Internal integration, Formal planning and Formal control mechanisms. Boehm's model (1991) suggests a comprehensive set of steps and guidelines to manage software development risks. Drawing from contingency research in Organizational theory and IS literature, Barki et al (2001) developed an integrative contingency model of software project risk management. Ropponen and Lyytinen (2000) researched on how risk management practices and environmental contingencies help in addressing the risk components in software projects. Kirsch (1996) proposed to build an integrated contingency model of software project management linking project management practices to the characteristics of the project and attributes of the individuals involved. Jiang et al (2000) studied the relationship between the major risk factors and the risk mitigation strategies. A similar analysis was performed by Addision and Vallabh (2002) to determine whether there were significant relationships between risks and risk controls in software projects.

## 2.3 Project outcome and its linkages with risk and risk management

A project is usually deemed as successful if it meets the desired requirements, is completed on time and is delivered within budget (Powell and Klein, 1996). A number of success criteria have been developed and empirically tested for IS projects. The triple criteria of project success – meeting cost, schedule and performance targets - have been widely used by researchers to analyze project success (Barki et. al 2001; Nidumolu 1995; Deephouse, 2005; Wallace, 2000; Ravichandran, 1996). Performance measures like meeting the original specifications, reliability, ease to use, portability etc. are subjective measures whereas time and cost overruns are objective measures. Studies are reported based on both subjective and objective measures (Nidumolu, 1996; Wallace et al., 2004b; Rai and Al-Hindi, 2000).

Linda Wallace (1999) validated the second order factor model of risk through the establishment of co-alignment, a structural model of the relationship between risk and project outcome. Jiang et. al. (2000) has independently done a study similar to the one described above and arrived at similar conclusions. But both these studies failed to include the risk management in the model which is stated as a major limitation by the authors. Barki et al (2001) showed how the outcome of the software project is influenced by the fit between the project risk and the project management. Deephouse et al (2005), through an exploratory study, developed a conceptual model linking effectiveness of software processes such as project planning, training, user contact, design reviews, prototyping and cross functional teams on project outcome. But there is no reference to the risk items. Nidumolu's (1995) model introduced residual performance risk as an intervening variable clarifying the relationship between risk, coordination mechanisms and performance. Na et al (2006) replicated this study in Korea revealing that both functional and system development risks are important predictors of software project performance. Jiang and Klein (2000) related software development risks to project effectiveness and Deephouse et al (2005) linked effectiveness of software processes to the project outcome.

Building on the limitations of the past research to include comprehensive measures of risk, risk management and project outcome into a single framework, we have undertaken this study. We are attempting to empirically validate the linkages among risk, risk management and project outcome in a single integrated model.

# 3. Research Methodology

The current research was designed as a survey. Operationally, risk is defined as the presence of the factors that will adversely affect the software development project. Risk management is defined as the presence of practices which are crafted to reduce the impact of risk in software projects. Project outcome is defined in terms of time
overrun, cost overrun and quality of the software developed. The level of risk, risk management and project outcome were measured by collecting data from software projects through validated instruments.

## 3.1 Instrument Development

An exhaustive survey of literature was performed to identify the major risk and risk management items from the previous studies. This list was edited by five senior software professionals working with leading companies in the IT industry as well as five senior professors in software engineering. The project outcome was measured with the validated tool used by Wallace (1999) with nine questions on the product quality and one question each on time and cost overrun. The draft questionnaire was pretested to a convenient sample of 100 software professionals with at least one year of software development project experience. The final instrument was developed incorporating the modifications based on the pretest data. It had 68 items representing the risk construct and 42 items representing the risk management construct. The Wallace (1999) instrument on project outcome was retained without any change.

The population for the study was defined as completed software development projects undertaken by software development organizations based in India. The data had to be provided by a project representative who had been part of the project from the beginning to the completion. The respondent was asked to read each statement and indicate the extent to which the risk / risk management item was present his/her project. The response format for each item was a five-point Likert-type scale ranging from “strongly disagree” to “strongly agree”. Product quality was measured through a five point rating scale where the respondent rated the software developed on nine dimensions of software quality. The time and cost overrun (or underrun) had to be indicated as a percentage of variation from the original estimate.

## 3.2 Data Collection

The survey was conducted in Chennai, Bangalore (tier I cities) Cochin and Trivandrum (tier II cities) in India. National Association of Software Companies (NASSCOM) is the most respected and recognized body of Indian software industry. NASSCOM listed companies account for over 90% of the revenue of the software industry in India. NASSCOM list of software companies in the selected cities was accepted as the sample frame for data collection. Letters were sent via email to the centre heads/HR managers of all the companies requesting them to allow their IT professionals to participate in the study. Reminder letters were sent after three weeks. 105 companies agreed to participate in the study. Data was collected from different types of projects and members in different roles but keeping the condition that only one response should be solicited from one project. The researchers distributed 1350 questionnaires via email to the 105 companies who agreed to participate. After two rounds of reminders, 574 filled questionnaires were collected back from 95 companies. Detailed examination of the data based on grossly missing or inappropriate values resulted in the deletion of 47 records. Thus the final data set had 527 usable records representing 527 projects from 95 companies. Table 1 shows how the sample projects are distributed across various categories.

<table><caption>Table 1
Type of the project in the sample</caption><thead><tr><td>Sl. No.</td><td>Domain</td><td>Percent (%)</td></tr></thead><tbody><tr><td>1</td><td>Business Applications</td><td>48.3</td></tr><tr><td>2</td><td>Engineering Applications</td><td>20.2</td></tr><tr><td>3</td><td>System Software</td><td>10.5</td></tr><tr><td>4</td><td>Web Application</td><td>17.5</td></tr><tr><td>5</td><td>Others</td><td>3.5</td></tr><tr><td>Total</td><td></td><td>100</td></tr></tbody></table>

## 4 Developing the Risk and Risk Management Measurement Models

The data was randomly divided into two groups: An estimation sample of 250 responses and validation (hold out) sample of 277 responses. Exploratory Factor Analysis (EFA) was performed on the estimation sample to identify the underlying dimension structure for the risk and risk management constructs. The identified factor structures were confirmed (validated) through a Confirmatory Factor Analysis (CFA) on the validation sample. This approach is
recommended by many researchers (Moore and Benbasat, 1991; Hair et. al., 2006, Thomson S.H. Teo et.al, 2006). Finally, the proposed model was tested on the validation sample using structural equation modeling.

## 4.1 Exploratory Factor Analysis (EFA)

The estimation sample data was subjected to an exploratory factor analysis using principal component analysis with varimax rotation. This has been the most popular and accepted procedure for similar data analysis (Moore and Benbasat, 1991, King and Teo, 1996, Thomson S.H. Teo et.al, 2006). The number of factors was to be decided looking into (a) percentage of variance explained (b) eigen values (c) interpretability of the factor structure (Hair et.al, 2006).

The analyses led to the representation of risk construct as a five factor structure and risk management as a four factor structure. Kaiser-Meyer-Oaklin measure of sampling adequacy and Bartlett Test of Sphericity values were seen to be acceptable. Items that did not load on a factor or cross load on multiple factors were identified. They were deleted if they didn't affect the face validity of the instrument in which case they were retained under the factor where the loading was highest. The final instrument had 55 risk items under risk construct loading onto five risk dimensions (Thomas et al, 2012) and 36 items under the risk management construct loading onto 4 risk management dimensions (Thomas et al, 2012).

## 4.2 Confirmatory Factor Analysis (CFA)

Confirmatory Factor Analysis (CFA) which is part of the structural equation modelling (SEM) is used to confirm a factor structure known beforehand or developed through EFA. The validation sample data was used to confirm the factor structures developed with EFA on the estimation sample. Software package AMOS 4.0 was used to do the analysis. The overall fit of a model was assessed using a number of fit indices like Goodness of Fit Index (GFI) (Joreskog and Sorbom, 1989), Comparative Fit Index (CFI) (Bentler, 1990), Non-normed Fit Index (NFI) (Bentler and Bonet't, 1980) and Root Mean Squared Residual (RMSR). The reliability of each dimension as well as the total construct was tested by computing Cronbach alpha (α) value. The risk and risk management dimensions with the fit indices are presented in tables 2 and 3. Thomas et.al (2012) describes in details the procedure followed.

<table><caption>Table 2
Fit indices for the measurement models of risk</caption><thead><tr><th>Dimensions of risk</th><th>No. of items</th><th>GFI</th><th>CFI</th><th>NFI</th><th>RMSR</th><th>Cronbach α</th></tr></thead><tbody><tr><td>Team Risk</td><td>26</td><td>0.894</td><td>0.953</td><td>0.913</td><td>0.048</td><td>0.9667</td></tr><tr><td>Proj. Plan & Exec Risk</td><td>14</td><td>0.804</td><td>0.807</td><td>0.790</td><td>0.09</td><td>0.9196</td></tr><tr><td>External Risk</td><td>5</td><td>0.914</td><td>0.837</td><td>0.831</td><td>0.08</td><td>0.8466</td></tr><tr><td>User Risk</td><td>6</td><td>0.962</td><td>0.967</td><td>0.958</td><td>0.07</td><td>0.8309</td></tr><tr><td>Proj. Complex Risk</td><td>4</td><td>0.990</td><td>0.986</td><td>0.982</td><td>0.03</td><td>0.7663</td></tr><tr><td>Full Risk Model</td><td>55</td><td>0.908</td><td>0.895</td><td>0.896</td><td>0.04</td><td>0.813</td></tr></tbody></table>

<table><caption>Table 3
Fit indices for the measurement models of risk management</caption><thead><tr><th>Dimensions of Risk Management</th><th>No. of items</th><th>GFI</th><th>CFI</th><th>NFI</th><th>RMSR</th><th>Cronbach α</th></tr></thead><tbody><tr><td>Execution Management Strategies</td><td>13</td><td>0.937</td><td>0.953</td><td>0.937</td><td>0.038</td><td>0.9204</td></tr><tr><td>Human Resource Management Strategies</td><td>11</td><td>0.930</td><td>0.913</td><td>0.895</td><td>0.050</td><td>0.8630</td></tr><tr><td>User Coordination Strategies</td><td>6</td><td>0.983</td><td>0.975</td><td>0.965</td><td>0.030</td><td>0.7001</td></tr><tr><td>Project Planning Strategies</td><td>6</td><td>0.994</td><td>0.999</td><td>0.989</td><td>0.034</td><td>0.8059</td></tr><tr><td>Full Risk Management Model</td><td>36</td><td>0.921</td><td>0.914</td><td>0.907</td><td>0.037</td><td>0.8340</td></tr></tbody></table>

## 5 Risk Management-Risk-Project Outcome Model

The objective of this research to empirically develop and validate an integrated model linking risk, risk management and project outcome. Risk management is designed to reduce risk in the project and reduction in risk is
expected to improve the project outcome (Nidumolu, 1995; Na et al, 2006). Thus the impact of the risk management on project outcome may be mediated by risk in the project. The proposed research model shown in figure 1 model postulates that risk management will be related to project outcome, both directly and indirectly, being mediated by risk. The hypothesized direct and indirect relationship between the predictor variables (risk, risk management) and the dependent variable (project outcome) is explored. Separate models were tested for each of the project outcome measures. Figure 2 shows the proposed model for the project outcome “quality”.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Integrated model</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>Fig. 2. Hypothesized model of quality</figcaption></figure>

Structural equation modeling (SEM) is often used for testing theory associated with latent variable models because it enables the inference of complex relationships among variables which cannot be directly observed. SEM is a multivariate statistical methodology, which takes a confirmatory approach to the analysis of a structural theory. SEM provides researchers with the ability to accommodate multiple interrelated dependence relationships in a single
model. (Hair et al., 1998). As mentioned earlier, the overall fit of a model was assessed using a number of fit indices as well as the values of the loading coefficients.

## 5.1 Modeling the Outcome Variable - Quality

The posited model presented in figure 2 contains two models — (1) the full direct model, which incorporates all identified paths and (2) the indirect model, in which the direct path (dotted) linking risk management to Quality will not be estimated. As both these models are nested (i.e., they are hierarchical models based on the same data set) and possess different degrees of freedom, their goodness-of-fit can be directly compared via multimodel analysis. In conducting a multimodel analysis using AMOS the procedure suggested by Ho (2006) is used. The step involves (1) defining the full direct model and (2) defining the indirect model in which the direct path linking risk management to Quality is constrained to zero. Constraining paths to zero is equivalent to those paths not being estimated.

<table><caption>Table 4
Fit measures for the quality models.</caption><thead><tr><th>Fit measures</th><th>Values for the direct model for quality</th><th>Values for the indirect model for quality</th></tr></thead><tbody><tr><td>Chi square (χ<sup>2</sup>)</td><td>72</td><td>134</td></tr><tr><td>GFI</td><td>0.974</td><td>0.953</td></tr><tr><td>CFI</td><td>0.988</td><td>0.971</td></tr><tr><td>RMSR</td><td>0.029</td><td>0.038</td></tr><tr><td>Akaike Criterion Information (AIC)</td><td>132</td><td>192</td></tr></tbody></table>

As seen in table 4, both the models are fitting the data very well. But the direct model has better fit indices values. The reduction in chi square (from 134 to 72) is statistically significant for a corresponding reduction of 1 in the degree of freedom as we move from indirect model to direct model. Therefore, although both models fitted the data relatively well, the direct model represents a significantly better fit than the indirect model, and is to be preferred. This conclusion is further supported by the Akaike Criterion Information (AIC) comparison statistics which shows a lower value for direct model which indicates that the direct model is both better fitting and more parsimonious than the indirect model. Table 5 presents the standardized regression coefficients of the paths in the hypothesized direct model.

<table><caption>Table 5
Standardized path coefficients for the quality model</caption><thead><tr><th colspan="2">Paths</th><th>Standardized Path coefficients</th><th>Significance (P)</th></tr></thead><tbody><tr><td>risk management</td><td>-> risk</td><td>-0.498</td><td>0.000</td></tr><tr><td>risk management</td><td>-> Quality</td><td>0.351</td><td>0.000</td></tr><tr><td>risk</td><td>-> Quality</td><td>-0.318</td><td>0.000</td></tr><tr><td>risk</td><td>-> complexity risk</td><td>0.892</td><td>0.000</td></tr><tr><td>risk</td><td>-> user risk</td><td>0.826</td><td>0.000</td></tr><tr><td>risk</td><td>-> external risk</td><td>0.685</td><td>0.000</td></tr><tr><td>risk</td><td>-> team risk</td><td>0.870</td><td>0.000</td></tr><tr><td>risk</td><td>-> plan & exec</td><td>0.658</td><td>0.000</td></tr><tr><td>risk management</td><td>-> exec mgmt</td><td>0.930</td><td>0.000</td></tr><tr><td>risk management</td><td>-> HR mgmt</td><td>0.865</td><td>0.000</td></tr><tr><td>risk management</td><td>-> user mgmt</td><td>0.752</td><td>0.000</td></tr><tr><td>risk management</td><td>-> planning mgmt</td><td>0.834</td><td>0.000</td></tr></tbody></table>
The results indicated that all the paths highly significant at p = 0.01 level. The risk had a significant negative link with risk management. Quality had a significant negative link with risk and positive link with risk management. Risk management is related indirectly to quality being mediated by risk. Thus better risk management result in reduced risk (β = -0.498) and reduction in risk results in increased quality (β = -0.318). Also, the better risk management results in a direct improvement in quality ((β = -0.351) and indirect improvement through risk (-0.498*-0.318= 0.158). The loadings of the first order factors onto risk and risk management constructs were strong and positive, thereby providing further support for the model (Segars and Grover., 1993).

## 5.2 Modeling the Outcome Variable -Time Overrun

A similar analysis was performed on the second project outcome variable “time overrun”. Both the direct and indirect models were tested. The values of the fit measures are reported in table 6:

<table><caption>Table 6
Fit measures for the time overrun models.</caption><thead><tr><th>Fit measures</th><th>Values for the direct model for time overrun</th><th>Values for the indirect model for time overrun</th></tr></thead><tbody><tr><td>Chi square (χ<sup>2</sup>)</td><td>68</td><td>73</td></tr><tr><td>GFI</td><td>0.957</td><td>0.953</td></tr><tr><td>AGFI</td><td>0.906</td><td>0.900</td></tr><tr><td>CFI</td><td>0.982</td><td>0.980</td></tr><tr><td>RMSR</td><td>0.154</td><td>0.155</td></tr><tr><td>Akaike Criterion Information</td><td>128</td><td>131</td></tr></tbody></table>

As seen both models are fitting well. The direct model shows slightly better fit. The standardized path coefficients for the direct mode are shown in table 7. The path linking risk management to time overrun is not significant at p = 0.01 level but significant at 5% level. The magnitude of the coefficient is very weak (β = -0.11). Thus it can be concluded that the impact of risk on time overrun is strong and significant(β =0.754). But the direct effect of risk management on the outcome variable is very weak (-0.11) and the effect is mainly indirect(-0.467*0.754 = -0.352) mediated through risk.

<table><caption>Table 7
Standardized path coefficients for the time overrun model</caption><thead><tr><th colspan="2">Paths</th><th>Standardized Path coefficients</th><th>Significance (P)</th></tr></thead><tbody><tr><td>Risk management -> risk</td><td></td><td>-0.467</td><td>0.000</td></tr><tr><td>Risk -> Time overrun</td><td></td><td>0.754</td><td>0.000</td></tr><tr><td>Risk management -> Time overrun</td><td></td><td>-0.110</td><td>0.030</td></tr><tr><td>Risk -> complexity risk</td><td></td><td>0.901</td><td>0.000</td></tr><tr><td>Risk -> user risk</td><td></td><td>0.841</td><td>0.000</td></tr><tr><td>Risk -> external risk</td><td></td><td>0.736</td><td>0.000</td></tr><tr><td>Risk -> team risk</td><td></td><td>0.900</td><td>0.000</td></tr><tr><td>risk -> plan & exec risk</td><td></td><td>0.595</td><td>0.000</td></tr><tr><td>risk management -> execution mgmt</td><td></td><td>0.915</td><td>0.000</td></tr></tbody></table>
<table><tr><td>risk management -></td><td>HR mgmt</td><td>0.862</td><td>0.000</td></tr><tr><td>risk management -></td><td>user mgmt</td><td>0.809</td><td>0.000</td></tr><tr><td>risk management -></td><td>planning mgmt</td><td>0.831</td><td>0.000</td></tr></table>

## 5.3 Modeling the Outcome Variable -Cost Overrun

The final outcome variable cost overrun was also modeled and analyzed similar to the other two variables. The values of the fit measures for the two models are reported in table 8.

<table><caption>Table 8
Fit measures for the cost overrun models.</caption><thead><tr><th>Fit measures</th><th>Values for the direct model for cost overrun</th><th>Values for the indirect model for cost overrun</th></tr></thead><tbody><tr><td>Chi square</td><td>70.7</td><td>70.9</td></tr><tr><td>GFI</td><td>0.957</td><td>0.956</td></tr><tr><td>AGFI</td><td>0.904</td><td>0.908</td></tr><tr><td>CFI</td><td>0.980</td><td>0.981</td></tr><tr><td>RMSR</td><td>0.152</td><td>0.162</td></tr><tr><td>Akaike Criterion Information (AIC)</td><td>132</td><td>131</td></tr></tbody></table>

The two models show equal fit and statistically there is no difference between the two. The reduction in chi square value is not significant for a one degree difference in the degrees of freedom. This supports the indirect model. The path coefficients (Table 9) shows that the path linking risk management to cost overrun is insignificant even at p=.05 level. Thus we conclude that the risk has direct impact on cost overrun where as the effect of risk management is indirect through the mediating variable risk.

<table><caption>Table 9
Standardized path coefficients for the cost overrun model</caption><thead><tr><th></th><th>Paths</th><th>Standardized Path coefficients</th><th>Significance (P)</th></tr></thead><tbody><tr><td>Risk management -></td><td>risk</td><td>-0.472</td><td>0.000</td></tr><tr><td>Risk</td><td>Cost overrun</td><td>0.559</td><td>0.000</td></tr><tr><td>Risk management -></td><td>Cost overrun</td><td>-0.019</td><td>0.730</td></tr><tr><td>Risk</td><td>complexity risk</td><td>0.901</td><td>0.000</td></tr><tr><td>Risk</td><td>user risk</td><td>0.854</td><td>0.000</td></tr><tr><td>Risk</td><td>external risk</td><td>0.727</td><td>0.000</td></tr><tr><td>Risk</td><td>team risk</td><td>0.890</td><td>0.000</td></tr><tr><td>risk</td><td>plan & exec risk</td><td>0.603</td><td>0.000</td></tr><tr><td>risk management -></td><td>execution mgmt</td><td>0.914</td><td>0.000</td></tr><tr><td>risk management -></td><td>HR mgmt</td><td>0.862</td><td>0.000</td></tr><tr><td>risk management -></td><td>user mgmt</td><td>0.813</td><td>0.000</td></tr><tr><td>risk management -></td><td>planning mgmt</td><td>0.827</td><td>0.000</td></tr></tbody></table>
# 6. Limitations of the Study

Risk and risk management are complex constructs which many researchers constantly work on. Hence it is quite possible that this research may not have captured every aspect of these construct even though an extensive literature review was conducted and experts in the area were consulted for inputs.

The study was designed as a single-respondent survey. Although it is common to use a single respondent in academic research, it would be more desirable to have multiple respondents from each project and independently assess risk in order to validate the results. Future researchers can address this issue by administering the instrument in this study to different stakeholders involved with the same project and comparing their perceptions of risk. The data is confined to projects executed with IT companies in India. It doesn't account for software development happening with non IT companies.

This research looks at software projects at a generic level. This lays the foundation for future research for studying the possible variation in the models depending on the organizational and project characteristics. Future researchers can follow the procedures laid out in this study to develop models on projects which are at different stages in project life cycle rather than studying them at the completion of the project.

# 7. Discussion and conclusion

This study showed the integrated relationship among risk, risk management and project outcome. The implications of this research for researchers and practitioners are highlighted.

The study showed that the impact of the risk management on project outcome is mediated by the levels of risk present. This indirect impact is more visible in the case of time and cost outcome measures. The quality of the software developed had a positive relationship with risk management and negative relationship with risk. The direct impact of risk management was seen to be stronger than the indirect impact through risk. The other outcome variables namely time overrun and cost overrun had strong negative relationship with risk. Risk management did not have much direct effect on overrun variables. Risk was seen to be acting as an intervening variable between risk management and overrun variables.

The direct link between risk and project outcome measures is consistent with literature. Wallace (1999) proved that the second order model of risk directly influenced all the three outcome measures. Jiang and Klein (2000) also demonstrated the negative impact of risk items on a range of project effectiveness measures.

The findings on the direct as well as indirect impact of risk management on project outcome also find support from literature. Deephouse et.al (2005) found that effectiveness of the software processes had a stronger and direct linkage with project quality than with overrun measures. Nidumolu (1995) showed that the risk control measures such as coordination strategies may have a direct and/or indirect impact on project outcome measures.

The impact and the importance of different risk and risk management dimensions can be understood looking at their loading coefficients in the models. The complexity risk and team risk are seen to be the most important risk dimensions in all the three models. Similarly execution management and HR management are seen to be the most effective risk management components.

It is important for project managers to understand this relationship among these constructs in the integrated environment. A clear assessment of risk helps project managers to perform risk control better. They can develop appropriate strategies for mitigating the risk in order to reduce the chance of project failure. Thus it can be concluded that only an integrated model accounting for the direct and indirect impact of risk and risk management can explain the variation in project outcome measures satisfactorily.

# 8 References

* Addison, T.: E-commerce project development risks: Evidence from a Delphi survey. International Journal of Information Management, 23(1), 25-40 (2003).

* Alter, S.: Implementation risk analysis. TIMS Studies in Management Sciences, 13 (2), 103-19 (1979).

* Alter, S., & Ginzberg, M.: Managing Uncertainty in MIS Implementation. Sloan Management Review, 23-31 (Fall 1978).

* Barki., H. & Rivard, S.: Toward an assessment of software development risk. Journal of Management Information Systems, 10, 203 (1993).

* Barki, H., Rivard, S., & Talbot, J.: Toward an assessment of software development risk. Journal of Management Information Systems, 10(2), 203-225 (1993).

* Barki, H., Rivard, S., & Talbot, J.: An integrative contingency model of software project risk management. Journal of Management Information Systems, 17(4), 37-69 (2001).
Bayer, J., & Muthig, D.: A view-based approach for improving software documentation practices. In 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems (2006)

Bentler, P.M.: Comparative fit indexes in structural models. Psychological Bulletin, 107, 238–246 (1990).

Bentler, P.M., & Bonett, D.G.: Significance tests and goodness of fit in the analysis of covariance structures. Psychological Bulletin, 88, 588-606 (1980).

Boehm, B.: Theory-W software project management principles and examples. IEEE Transactions on Software Engineering, 15(7), 902-916 (1989).

Boehm, B. W.: Software risk management: Principles and practices. IEEE Software, 8(1), 32-41 (1991).

Charette, R. N.: Software engineering risk analysis and management. McGraw-Hill Software Engineering Series (1996).

Chatzoglou, P.D., & Diamantidis, A.D.: IT / IS implementation risks and their impact on firm performance. International Journal of Information Management, 29(2), 119-128 (2009).

Costa, H.R., Barros, M.O., & Travassos, G.H.: Evaluating software project portfolio risks. Journal of Systems and Software, 80, 16–31 (2007).

Cuellar, M.J., & Gallivan, M.J.: A framework for ex ante project risk assessment based on absorptive capacity. European Journal of Operational Research, 173, 1123–1138 (2006).

Davis, G.B.: Strategies for Information Requirements Determination. IBM Systems Journal 21(1), 4-30 (1982).

Deephouse, C., Mukhopadhyay, T., Goldenson, D. R., & Kellner, M. I.: Software Processes and Project Performance. Journal of Management Information Systems (Winter 1995-96) 12(3), 185-203 (2005).

Ewusi-Mensah, K., & Przasnyski, Z. H.: On information systems project abandonment: An exploratory study of organizational practices. MIS Quarterly, 15(1), 67-85 (1991).

Fairley, R.: Risk management for software projects. IEEE Software, 11(3), 57–67 (1994).

Ginzberg, M.: Early diagnosis of MIS implementation failure: Promising results and unanswered questions. Management Science, 27(4), 459-478 (1981).

Hair, J.F. Jr., Black, W.C., Babin, B.J., Anderson, R.E., & Tatham, R.L.: Multivariate data analysis, Pearson Prentice-Hall, Englewood Cliffs, NJ (2006).

Hair, J.F., Anderson, R.E., Tatham, R.L., & Black, W.C.: Multivariate Data Analysis, Prentice-Hall International, New Jersey, USA (2006).

Ho, Robert,: A Handbook of Univariate and Multivariate Data Analysis and Interpretation with SPSS, Francis and Taylor Group, LLC (2006)

Hofstede, G.: Cultures and organizations: Software of the mind: Intercultural cooperation and its importance for survival, London: McGraw-Hill (1980).

Iversen, J.H., Mathiassen, L. & Nielsen, P.A.: Managing risk in software process improvement: an action research approach. MIS Quarterly, 28, 395–433 (2004).

Jiang, J. & Klein, G.: Information system success as impacted by risks and development strategies. IEEE Transactions on Engineering Management, 48, 46–55 (2004).

Jiang, J. J., & Klein, G.: Software development risks to project effectiveness. Journal of Systems and Software, 52(1), 3 (2000).

Jiang, J. J., & Klein, G.: The importance of building a foundation for user- involvement in information system projects, Project Management Journal, 33(1), 20–26 (2002).

Jiang, J., & Klein, G.: Risk to different aspects of system success. Information & Management, 36(5).263-271.

Jones, C.: Assessment and control of software risks. Englewood Cliffs, NJ: Yourdon Press (1999).

Jørgensen, M and Moløkken-Østvold: How large are software cost overruns? A review of the 1994 CHAOS report, Information and Software Technology 48, 297-301 (2006)

Keil, M., Cule, E. P., Lyytinen, K., Schmidt, C., & Roy, A.: Framework for identifying software project risks, Communications of the ACM, 41 (11), 765-83 (1998).

King, W. R., & Teo, T. S. H.: Key dimensions of facilitators and inhibitors for the strategic use of information technology. Journal of Management Information Systems, (12), 4 (1996).

Kirsch, L.J.: The management of complex tasks in organizations: controlling the systems development process. Organization Science, 7, 1–21 (1996).

Lyytinen K., Mathiassen L. & Ropponen, J.: Attention Shaping and Software Risk – A categorical Analysis of Four Classical Risk Management Approaches. Information Systems Approach, 9(3), 233 – 255 (1988).

Lyytinen, K.: Expectation failure concept and systems analysts view of information system failures: Results of an exploratory study. Information and Management, 14, 45–46 (1988).

Lyytinen, K., Mathiassen, L., & Ropponen, J.: An organizational analysis of software risk management approaches. Working Paper, University of Jyvaskyla, Jyvaskyla, Finland (1993).

Lyytinen, K., Mathiassen, L., & Ropponen, J.: Attention shaping and software risk – A categorical analysis of four classical risk management approaches. Information Systems Approach, 9(3), 233–255 (1998).

Malhotra, R., & Temponi, C.): Critical decisions for ERP integration: Small business issues. International Journal of Information Management, 30(1), 23–37(2010).

Mann, J.: Undergraduate global IT education: An experiential approach using the concept of fit. IRMA Conference 2000, 917-918 (2002).

McFarlan, F. W.: Portfolio approach to information systems. Harvard Business Review, 59(5), 142-150 (1981).
Moore, G.C., & Benbasat, I.: Development of an instrument to measure the perceptions of adopting an information technology innovation. *Information Systems Research*, 2(3), 173–191 (1991).

Moore, J.E.: One road to turnover: an examination of work exhaustion in technology professionals. *MIS Quarterly*, 24(1), 141-68 (2000).

Moynihan, T.: How experienced Project Managers access risk. *IEEE Software*, 14(3), 35-41(1997).

Mursu, A.: From software risks to sustainable information systems: Setting the stage for a Delphi study in Nigeria. *Journal of Global Information Technology Management*, 2, 57-71 (1997).

Mursu, A.: University of Jyväskylä, Dept. of Computer Science and Information Systems, PL 35, FIN-40351 Jyväskylä, Finland (2000).

Na, K., Li, X., Simpson, J.T., Kim, K.: Uncertainty profile and software project performance: A cross-national comparison, *The Journal of Systems and Software*, 70, 155-163 (2004).

Na, K., Simpson, J.T., Li, X., Singh, T., & Kim, K.: Software development risk and project performance measurement: Evidence in Korea. *Journal of Systems and Software*, 80(4), 596-605 (2006).

Neumann, P.G.: Computer related Risks, Addison-Wesley, Reading, Massachusetts (1995).

Nidumolu, S.: The Effect of Coordination and Uncertainty on Software Project Performance: Residual Performance Risk as an Intervening Variable. *Information Systems Research*, 191-219 (1995).

Powell, P. L., & Klein, J. H.: Risk Management for Information Systems Development. *Journal of Information Technology*, 11, 309-311(1996).

Rai, A., Al-Hindi, H.: effects of development process modeling and task uncertainty on development quality performance. *Information and Management* 37, 335–346 (2000).

Ravichandran, T.: Special issue on component-based software development. *ACM SIGMIS Database*, 34(4),45-46 (2003).

Ropponen, J., & Lyytinen, K.: Can software risk management improve system development: An exploratory study? *European Journal of Information Systems*, 6(1), 41-50 (1997).

Ropponen, J., & Lyytinen, K.: Components of software development risk: how to address them? *A project manager survey*. *IEEE Transactions on Software Development*, 26 (2), 98–112 (2000).

Schmidt, J., & Kozar, K.: Management's role in information system development failures: A Case Study. *MIS Quarterly*, 2, 7-16 (1978).

Schmidt, R., Lyytinen, K., Keil, M., & Cule, P.: Identifying software project risks: an international delphi study. In *Proceedings of the 17th International Conference on Information Systems, Cleveland, OH* (1996).

Segars, A.H., & Grover, V.: Re-Examining Perceived Ease of Use and Usefulness: A Confirmatory Factor Analysis. *MIS Quarterly*, 17(4), 517 – 525(1993).

Shan L., Jinlong Z., Keil M., & Chen, T.: Comparing senior executive and project manager perceptions of IT project risk: Chinese Delphi study. *Information Systems Journal* (2009).

Taylor, H.: Risk management and problem resolution strategies for IT projects: prescription and practice. *Project Management Journal*, 37, 49–63 (2006).

Teo, T.H., Ranganathan, C., & Dhaliwal, J.: Key dimensions of inhibitors for the deployment of web-based business-to-business electronic commerce. *IEEE Transactions on Engineering Management*, 53(3) (2006).

Thomas Sam & Bhasi M: How does software project risk vary across projects? An exploratory study from India, *International Journal of Intercultural Information Management*, Volume 2, No 4 (2011).

Thomas Sam & Bhasi M : A Structural Model for Software Project Risk Management, Vilakshan XIMB Journal of management, Vol VIII (2011(2)).

Thomas Sam & Bhasi M.: Software Development Project Risk: A Second Order Factor Model Validated in the Indian Context, *International Journal of Information Technology Project Management*, 3(4), 41-55 (2012).

Tiwana, A., Keil, M.: The One-Minute Risk Assessment Tool. In: *Communications of the ACM*, 47,73-78 (2004).

Wallace, L.: The development of an instrument to measure software project risk. Thesis 1/1999, Georgia University (1999).

Wallace, L., & Keil, M.: Software project risks and their effect on outcomes. *Communications of the ACM*, 47(4), 68 – 73 (2000).

Wallace, L., Keil, M., & Rai, A.: Understanding Software Project Risk: A Cluster Analysis. *Information and Management* 42(1), 115 – 125 (2004).

Wen-Ming, H., & Sun-Jen, H.: An empirical analysis of risk components and performance on software projects, *The Journal of Systems and Software*, 80, 42–50 (2007).