Framework of Goal-driven Risk Management in Software Development Projects Using the Socio-technical Systems Approach

Abstract

Previous studies have identified the influence of goal agreement on requirement elicitation in software projects, but they have not addressed how it influences risks in projects. The purpose of this study is to examine the influence of goal identification and agreement on software project risks. With socio-technical systems theory as the backdrop, we used a goal-oriented perspective to understand how the social subsystem influences the technical subsystem of a software development project. In an empirical study with 411 responses from software project developers and managers in India and using structural equation modelling, the causal linkages between goal orientation and project risk variables have been examined. The results indicated that the early adoption of goal-driven risk management reduces the social context risks which, in turn, reduces the project management risk. The study also revealed that the product artefact is independent of whether the system was completed within budget and schedule. To design the risk management strategy, project managers should consider the relationship between social context risk and project management risk and the implications of these relationships on project performance.

Keywords

Goal oriented project management project performance risk risk management social risk project management risk

Introduction

One of the important considerations to keep projects on track is risk identification, as overlooking any risk can lead to improper prioritization and other undesirable consequences thereafter (Liu & Chiu, 2017). Organizations have been following the risk management process, a systematic approach of identifying, analysing and responding to risks (Kutsch, 2008) to reduce exposure to potential losses (Alberts & Dorofee, 2010; Brown et al., 2000; Du et al., 2007; Project Management Institute, 2017). Despite following processes, project managers often fail to identify potential risks which negatively influence their decision-making (Keil et al., 2013). Nearly two-thirds of projects considered non-risky by managers ultimately failed (Verner & Evanco, 2005). One potential reason for such failures is the level of understanding reached between the development and the client teams (Purvis et al., 2016). Meeting the client’s needs depends on the ability of the developers to complete the tasks assigned to them (Maruping et al., 2009). However, it has been found that the requirements tend to change due to frequently changing business needs (Chakraborty et al., 2010; Wallace et al., 2004). The volatile and unclear requirements influence the ability to execute the projects (Wallace et al., 2004). Risk management integrates the technological and business expertise of the development team and personnel in the client organization (Patnayakuni et al., 2007).

Risk management includes both the technical aspects of project management set by the processes, principles, guidelines and tools, and the human aspect of project management concerned with the attitude and skills of people. With this interrelationship between the technical aspect and human aspect of project management, risk management can be viewed as a socio-technical system. Researchers have argued that socio-technical problems are interrelated, and the solution to one problem depends on solving other problems (Emery, 1959). Hence, the study used the socio-technical systems approach to explore the influence of social subsystem on technical subsystem in software project risk management.

There has been a great deal of emphasis on setting common objectives to resolve disagreements (Liu et al., 2011) and ensure project progress (Keil et al., 2013; Maguire & Redman, 2007). Goal identification and agreement by the stakeholders have been found to create a shared understanding of the tasks to be undertaken and the product to be developed (Lim & Mohamed, 1999). Goal orientation has been adopted in project management (PMI, 2013, 2014) and requirement elicitation in the software engineering domain (Lamsweerde, 2000). The goal-oriented requirement engineering (GORE) helps to elicit, elaborate and structure requirements by mapping the stakeholders’ needs and expectations for software artefact under consideration (Lapouchnian, 2005; Letier, 2001). Although these studies have shared insights regarding the influence of goal agreement on requirement elicitation and project performance, they have not addressed how it influences risks in projects.

This study advances the understanding of risk management in software projects by exploring the influence of agreement on project goals and deliverables on software project risks and performance. In this study, we argue that an agreement on goal and deliverables by the project stakeholders influences the social subsystem of the project by reducing the conflict between the development team and the client team which in turn influences the technical subsystem by supporting requirement elicitation and project execution. This, in turn, enhances the project performance. In doing so, the study addresses the following research question:

RQ1a: What are the socio-technical risk dimensions in software development projects?

RQ1b: How do these risk dimensions influence each other?

RQ2: How do the goal identification and agreement influence the risks and performance of software development projects?

To address these questions, we draw upon two theoretical perspectives. First, we use the socio-technical systems theory to understand how does the social subsystem of project management, that is, the understanding between the developer team and the client team influence the technical subsystem of the project management, that is, requirement elicitation and project execution. Second, we use the goal-oriented perspective to approach software project risk management. Specifically, we focus on (a) identifying social context risk (SCR) dimension, representing the social subsystem of software project management and their influence on the project management risk (PMR) dimension that represents the technical subsystem of project management, (b) understanding how do these risks influence the project performance and (c) building and testing a framework of goal-driven risk management and assessing its impact on the risks and performance of software projects.

The study introduces a framework of goal-driven risk management that integrates goals, risk and project performance and examines the influence of SCRs on PMRs and performance in software projects in India. The study found that goal agreement contributes to project performance by reducing the risks. Another contribution of the study is that an agreement on goals does not contribute directly towards reducing risks associated with the technical subsystem of the project represented by requirement risk and execution risk, but indirectly by reducing the risks associated with the social subsystem of the project represented by client risk and development team risk.

Literature Review

In this section, we provide an overview of project risks, goal perspective and socio-technical systems in the context of software projects. We develop our research framework using these theoretical perspectives.

Software Project Risk

Risks have the potential to negatively impact project objectives of scope, time and cost due to which project activities may take longer than planned. Software projects, being a multifaceted and complex activity, face various risks related to technology, processes and people (Ke & Zhang, 2011; Nelson & Jansen, 2007; Nelson & Morris, 2014; Qureshi & Fang 2011; Sarker & Sarker, 2009; Sarker et al., 2011). Over the years, researchers have empirically categorized the types of risks in software development projects (Addison & Vallabh, 2002; Barki et al., 1993; Boehm, 1991; Han & Huang, 2007; McFarlan, 1982; Schmidt et al., 2001; Sharma et al., 2011; Wallace et al., 2004). These studies have mainly focused on the technical aspect of risk management, that is, the checklists, processes, tools and frameworks. They have not taken into consideration the influence of the social context of the projects. The study by Wallace et al. (2004) used the socio-technical systems theory and showed the interrelationship between the technical subsystem and social subsystem risks and their influence on project performance.

Software Projects as Socio-technical Systems

Socio-technical systems theory (Emery, 1959) assumes that an organization and its work system are made up of two independent and interacting systems: the social and the technical subsystems. This system views the technical subsystem as the processes, tasks and technology needed in the work system. The people attribute such as attitudes, values and skills constitute the social subsystems. It is the interaction between these two subsystems that produces the output of the work system. In the context of software projects, the technical subsystem is represented by the tasks to be performed in accordance with the processes, guidelines and standards to produce a technical artefact, and the social subsystem is constituted by the people associated with these tasks and the organization where the project is situated (Wallace et al., 2004). As a socio-technical system, the system behaviour, that is, the output of the project will be impacted by the interaction of the social and technical subsystems (Trist, 1981). Software projects create a technical artefact based on a set of requirements. The processes, tools and techniques to manage projects constitute the technical subsystem, whereas people and their attitudes and skills constitute the social subsystem.

Software Project Risk Management

Software project risk management is a systematic approach of identifying, analysing and responding to risks (Kutsch, 2008) for proactive decision-making (Brown et al., 2000) to reduce exposure to potential losses (Alberts & Dorofee, 2010; Brown et al., 2000; Du et al., 2007; Project Management Institute, 2017). Over the years, various frameworks and models of software project risk management (Alberts & Dorofee, 2010; Boehm et al., 1995; Carbone & Tippett, 2004; Kontio, 2001; Manalif, 2013) have been proposed which take into consideration the software development lifecycle. As we will argue later, when project goals are identified and agreed upon by the client, requirements tend to be stable and reduce overall project risks. Any reduction in risk means less time spent on corrective action, thereby improving risk management and project performance (Chiang & Mookerjee, 2004). Given our interest in understanding the impact of goal-driven risk management on project performance, we examine the role of goal identification and stakeholder agreement on SCR, PMR and project performance.

Goal-driven Approach in Software Projects

The recent development in the project management literature has been to align project goals with the organizational goals to achieve project success (PMI, 2014). It has been observed that the involvement of senior executives supports the articulation of purpose, value and rationale and reduces the resistance that accompanies large change (The Standish Group, 2016).

Goal orientation has been adopted for software engineering requirements. GORE maps the stakeholders’ needs and expectations for software artefact under consideration (Lapouchnian, 2005; Letier, 2001) and ensures requirement completeness by avoiding irrelevant requirements (Lamsweerde, 2000). Without understanding the organizational context, low-level requirements are produced that significantly impact software quality (Lapouchnian, 2005). Setting expectations at the onset of the project contributes to the alignment between project deliverables and expectations so that the work can be guided along those lines (Lim, & Mohamed, 1999). A study by Islam et al. (2014) found that integrating goal-driven risk management into the requirement engineering phase provides early warning about problems in the project and contributes to overall project success. These studies indicate the importance of adopting a goal-driven approach for project management and software requirement elicitation. Notably, these studies have established a linkage between goal setting and performance, but they have overlooked its impact on risks. Risks impede productivity. For software development projects, refining the development process to reduce the effort spent on corrective actions can enhance productivity (Chiang & Mookerjee, 2004). This is the premise of the study to devise a framework to reduce risks so that the effort and resources spent on mitigation and control are reduced.

Risk management impacts the cost management of a project (Allen et al., 2015) and may negatively impact project cash flows (Sato & Hirao, 2013). One of the reasons cited often for IT project failures is a lack of top management commitment (Liu et al., 2015). A lack of communication between top management and project team leads to risk avoidance and downplaying risks (Bhoola et al., 2014) which defeats the purpose of risk management (Liu et al., 2015). Effective risk management requires top management commitment, employee training and effective communication within and outside the organization (Dandage et al., 2018). Standards such as the International Project Management Institute (IPMA) and Project Management Body of Knowledge (PMBOK) provide guidelines to achieve project objectives (IPMA, 2015; Project Management Institute, 2017). Although they provide methods and techniques for risk management and the classification of risks, they do not provide any guidance on possible interactions among the risks.

Although software project risk management has been researched widely, two gaps in understanding remain. First, these studies have primarily focused on the technical aspects of risk management constituted by processes, standards, guidelines and techniques. The social aspects comprising the interaction among project participants and the organization and their influence on the technical aspects of the project risks have not been taken into account. Second, prior to this, software project risk management research has focused primarily on improvising the risk management process. It has not taken into consideration the goal identification and its impact on the social aspects of the project. Goal identification as a mediating mechanism—goal identification → software project risks → software project performance causal chain—has not been empirically tested as a mediated relationship. An understanding of the impact of goal setting on these risks and project performance could guide project stakeholders in managing risks better.

Framework of Goal-driven Risk Management and Project Performance

The framework development was guided by the project management literature and socio-technical systems theory. The socio-technical design emphasizes establishing a fit between technical and social subsystems (Pava, 1983).

The proposed theoretical model has four dimensions of software project risks, namely execution risk, requirement risk, client risk and development team risk (Table 1) which are the building block for the higher level latent constructs, namely SCR and PMR. The higher level of latent constructs is used to examine the relationship between project risk and project performance.

Table 1.

Risk Dimensions

Dimension	Description	Representative References
Execution risk	Project execution adds to project riskiness as projects not monitored closely enough may go off track or may not produce the intended outcome	(Foo & Muruganatham, 2000; Mitchell, 2006; Procaccino et al., 2002; Wallace et al., 2004)
Requirement risk	Requirements not adequately identified or incorrect requirements or unclear requirements may increase problems associated with software system development	(Addison & Vallabh, 2002; Keil et al., 1998; Nakatsu & Iacovou, 2009; Sharma et al., 2011; Wallace et al., 2004)
Client risk	A client with a negative attitude towards the project or not committed to the project is less likely to cooperate with the development team leading to impediment toward the project	(Addison & Vallabh, 2002; Keil et al., 1998; Mitchell, 2006; Nakatsu & Iacovou, 2009; Wallace et al., 2004)
Team risk	Team risk issues such as inexperienced or inadequately trained team members or lack of domain knowledge that increases the riskiness of a project	(Foo & Muruganatham, 2000; Jiang & Klein, 2000; Nakatsu & Iacovou, 2009; Procaccino et al., 2002; Sharma et al., 2011; Wallace et al., 2004)

Source: The author.

Key activities of project management are project planning, specifications and control (Keil et al., 2003). The leader of the project team identifies the central problem to solve and with input from the sponsor and stakeholders determines the project’s objectives and scope and the activities that will deliver the desired results (Barber & Warn, 2005). Thus, the PMR is modelled as a construct consisting of two underlying risk dimensions: requirement risk and execution risk.

A software project is embedded in a social context (Wallace et al., 2004) where the client and the development team need to work towards agreed upon goals (Liu & Chiu, 2017). Understanding other team member’s perspectives (Hsu et al., 2014) and knowledge sharing throughout the development process (Chiocchio et al., 2011) helps to achieve an effective outcome (Conboy & Morgan, 2011). The absence of a cohesive group may increase the riskiness of the project. Thus, the SCR can be modelled as a construct consisting of two underlying dimensions: team risk and client risk.

Project performance has been conceptualized as process performance, that is, success of the development process and product performance, that is, success of the developed system (Cooke-Davies, 2002; Nidumolu, 1996; Wallace et al., 2004).

Hypotheses Development

A software project is embedded in a social context (Wallace et al., 2004) with participation from client and developers to develop a technical artefact based on a set of requirements. A cohesive group of client, developers and project managers is able to determine project scope and required resources (Jiang et al., 2006), discover inconsistent expectations, potential problems in determining product design (Hsu et al., 2014) and build procedures to resolve controversies (Larson, 1997). Client participation helps tailor the system’s attributes as per their specifications (Nidumolu, 1996). On the contrary, if the client is resistant to change, it may lead to a conflict between the client and the development team. If the team members are not committed, it will make it difficult to determine product design, produce an accurate set of requirements and result in a weak business plan. On the basis of the findings, we suggest that SCR, determined by team and client risk, has an impact on PMR determined by requirement and execution risk.

H1 SCR will have a significant impact on PMR.

Projects fail because of a weak business plan, not addressing risk during the project planning process (Whittaker, 1999) or too little attention to planning before project initiation (Keil et al., 2003). Project planning specifies a set of decisions related to tasks to produce the desired product or service (Zwikael & Sadeh, 2007). Poor planning impedes the execution and achievement of project targets (Globerson & Zwikael, 2002). When teams engage in planning, they can develop a clear path to meet project objectives and mitigate risks (Sauer et al., 2007). Also, client interaction at the time of planning facilitates efficient system design based on client feedback (He & King, 2008). With clear and realistic goals, managers are able to clarify expected outcomes, explicate elaborate needs, accomplish tasks (Locke & Latham, 2002) and determine development procedures (Jiang et al., 2002). Thus, we hypothesize

H2 Goal identification and agreement at the planning stage will have a significant impact on:

H2a Social context risk

H2b Project management risk

H2c Risk management.

Project performance is described in terms of (a) process performance, which describes the performance of the software development process and (b) product performance, which is the performance of the developed system (Nidumolu, 1996; Wallace et al., 2004). Both the process and product performance need to be considered because a project that delivered high-quality software may have significantly exceeded its time and cost estimates. On the other hand, well-managed projects, completed within time and cost, may deliver poor-quality products (Pollack & Adler, 2015). The project manager guides the team to follow a project management methodology to keep the project on track. Unclear, ambiguous requirements, or not adhering to the project management methodology, may result in a delay in project completion and develop a poor-quality product. PMR can directly affect performance. Thus, we hypothesize

H3 Project management risk will have a significant impact on

H3a Process performance

H3b Product performance.

A poorly managed project is more likely to yield a system which does not meet user specification or is judged poorly in terms of quality and satisfaction (Wallace et al., 2004). Projects that are on time and within budget are found to perform better and deliver high-quality products (Maruping et al., 2009). A project that is completed late and over budget is less likely to meet goals defined by the stakeholders (Turner & Zolin, 2012). Thus, we hypothesize

H4 Process performance will have a significant impact on product performance

Reducing project risks helps avoid rework and other unnecessary efforts. By adopting a risk management process, threats posed by project risks can be overcome (Schmidt et al. 2001; Wallace et al. 2004; Wu et al., 2015). Software development projects, whose risks are under control, enable to estimate resources more accurately and make better planning (Boehm, 1989) thereby leading to a more mature software development process. Using processes and tools to manage risks allows knowledge exchange between project team members (Teller et al., 2014). At the same time, formal controls can lower the flexibility of projects and can be counter-productive (Sethi & Iqbal, 2008). These findings suggest that risk management will affect the process and product performance.

H5 Risk management will have a significant impact on

H5a Process performance

H5b Product performance.

The proposed research framework is described in Figure 1.

Figure 1.

Source: The author.

As the study needed to establish causal linkages between latent constructs, structural equation modelling (SEM) was used.

Method

This section describes the sample population and the survey instrument. For the empirical study, a survey instrument was designed to measure the goal changes, risks, risk management and project performance in software development projects.

Sample

For testing the research hypotheses, survey data were used. A two-step process was adopted for data collection: cluster and purposive sampling. Purposive sampling is considered desirable when a known characteristic of the population is to be studied intensively (Kothari, 2004). As per NASSCOM (2017) data, 67% of IT companies are concentrated in Bangalore, Chennai, Delhi-NCR, Hyderabad and Pune which are considered the IT hubs of India and attract a skilled, knowledge-intensive workforce. Software development organizations in these cities were selected for data collection. The study intended to identify the technical and managerial aspects of project management. Because the study focused on risk management and performance of software development projects and emphasizes stakeholder view on risk and performance, a purposive sampling strategy was used to target software project professionals with 4–15 years of experience (Purvis et al., 2016).

The study used SEM for data analysis. Bentler and Chou (1987) recommend 15 cases per measured variable for SEM. A large sample is required if data are not normally distributed or have some other flaws. Since the study has 26 measured variables, a minimum sample of 390 is required. The study had 411 respondents.

The survey was administered through a web-based tool and also through face-to-face meetings. From NASSCOM, a list of software companies in the software hubs was identified. Potential respondents were contacted through email. A covering letter outlining the purpose of the research study and expected outcomes was also sent along with the survey instrument.

Instrument

Researchers have empirically categorized the source and types of risks associated with software development projects to better manage the risks (Boehm, 1991; McFarlan, 1982). For example, McFarlan (1982) identified 54 risk factors under 3 risk dimensions; Boehm (1991) 10 risk factors, Barki et al. (1993) 55 risk factors under 5 risk dimensions; Schmidt et al. (2001) 33 risk factors under 14 risk dimensions; Addison and Vallabh (2002) 28 risk factors under 10 risk dimensions; Wallace et al. (2004) 27 risk factors under 6 risk dimensions; Sharma et al. (2011) 23 risk factors categorized under 4 risk dimensions. The study adopted items from multiple sources to measure risks, risk management and planning. For project performance, the study used the scale developed by Wallace et al. (2004).

Method bias has an influence on responses when respondents cannot or are unwilling to provide accurate responses (Podsakoff et al., 2012). Some of the factors that cause method bias are education, cognitive sophistication (Krosnick, 1999; Krosnick & Alwin, 1987), lack of experience thinking about the topic (Fiske & Kinder, 1981; Schwarz et al., 1992), complex or abstract questions (Doty & Glick, 1998; Krosnick, 1991) and questions that rely on retrospective recall (Krosnick, 1991).

Podsakoff et al. (2003) suggested procedural remedies and statistical remedies to control common method biases. Statistical remedies control the effects of method biases after the data have been gathered. Harman single-factor technique (Harman, 1960) was used to test whether data may be influenced by biases. Using the exploratory factor analysis (EFA), all the factors were loaded onto a single factor. The total variance for this single factor was 24%, indicating the absence of common method bias. Procedural remedies include careful design of the study to minimize the effects of method bias. In order to reduce responses that are socially desirable, lenient and consistent, a covering letter was sent along with the questionnaire, ensuring respondents about their anonymity. Reverse coded items were introduced to reduce the potential effects of response pattern bias (Idaszak & Drasgow, 1987). For the study, software project professionals were selected as respondents as they are most familiar with the activities within their projects and project outcomes (Jiang et al., 2006; Liu & Chiu, 2017; Purvis et al., 2016). The respondents were asked to rate their perception about risk, risk management and project performance in reference to their last executed project to avoid any issues arising out of retrospective recall. Face validity of the questionnaire was conducted, and the items were modified, added or deleted, to ensure that the language is clear and concise and avoids complicated syntax.

Results

Since the study aimed at examining the causal linkages between the independent and dependent variables, SEM was used using a two-step approach of testing the measurement model before estimating the full structural model (Anderson & Gerbing, 1988). Confirmatory factor analysis was conducted to test that indicator variables load highly on factors established by EFA and do not load highly on unrelated factors. SPSS Amos 24 statistical package was used to analyse the relationship among variables.

Validity and Reliability of Measurement Items

EFA with varimax rotation using SPSS Amos 24 was used to analyse the relationship among variables. Variables with a loading factor above 0.7 were retained as items to be used for the final survey. Dimension reduction was confirmed by composite reliability (CR) of more than 0.7 (Akter et al., 2011) and average variance extracted was more than 0.5 (Fornell & Larcker, 1981).

Construct reliability and validity were established through internal reliability and convergent validity. The convergent validity was established through composite reliability (CR) recommended >0.7 (Akter et al., 2011), Cronbach’s alpha (CA) recommended to be >0.7 (Hair et al., 2011) and average variance extracted (AVE) recommended >0.5 (Fornell & Larcker, 1981). The final scale is presented in Table 2.

Table 2.

Final Survey Items

Construct	Item Abbreviation	Items	Factor Loading
Planning CR: 0.862 AVE: .611 CA: 0.799	Pl1	The business goals and objectives were identified for the project	0.869
	Pl2	The project goals were identified and agreed upon with the client	0.827
	Pl3	The project deliverables and related schedule were agreed upon by the clients	0.741
Execution Risk CR: 0.794 AVE: .66 CA: 0.641	Ex1	The project lacked effective project management methodology	0.865
Execution Risk CR: 0.794 AVE: .66 CA: 0.641	Ex2	The project lacked scientific methods for project execution	0.756
Requirement Risk CR: 0.85 AVE: 0.586 CA: 0.784	Rq1	The project scope kept changing during the project	0.837
	Rq2	Requirements were miscommunicated	0.763
	Rq3	The project had changing requirements throughout the project execution	0.731
	Rq4	New requirements were introduced during the project	0.727
Client Risk CR: 0.85 AVE: 0.586 CA: 0.786	Cl1	There was a difference of opinion between client and development team members	0.777
	Cl2	The project experienced a lack of adequate client involvement	0.774
	Cl3	There was a lack of client top management commitment to the project	0.757
Team Risk CR: 0.888 AVE: 0.666 CA: 0.843	Tm1	There was a lack of commitment from the project development team	0.885
	Tm2	There was a lack of availability of the domain expert	0.841
	Tm3	The team had a low morale	0.784
	Tm4	There were inadequate skills and means to finish the project	0.748
Risk Management CR: 0.917 AVE: 0.68 CA: 0.899	RM1	A comprehensive risk management process exists for the project	0.879
	RM2	The risk management process is integrated into the development process	0.860
	RM3	Risk factors were identified at the start of the project and agreed upon by the client	0.852
	RM4	The organization has a mechanism to perform impact analysis of the risk on the project	0.786
Process Performance CR: 0.889 AVE: 0.668 CA: 0.862	Ps1	The system was completed within budget	0.909
Process Performance CR: 0.889 AVE: 0.668 CA: 0.862	Ps2	The system was completed within schedule	0.897
Product Performance CR: 0.898 AVE: 0.815 CA: 0.85	Pd1	The application developed is reliable	0.907
	Pd2	The developed application meets the quality standards	0.823
	Pd3	The developed application is user-friendly and easy to use	0.766
	Pd4	The development process emphasizes to develop reusable code	0.764

Source: The author.

Notes: CR = composite reliability; AVE = average variance extracted; CA = Cronbach’s alpha.

The variance extracted test was used to test the discriminant validity (Fornell & Larcker, 1981) by comparing the variance extracted estimates for two constructs of interest with the square of the correlation of two constructs. The diagonal elements in Table 3 are the variance extracted estimates for each of the constructs and the off-diagonal elements are the squared correlation between the constructs. The test demonstrated both convergent and discriminant validity as variance extracted estimates for two constructs are greater than the squared correlation between constructs (Hatcher, 1994).

Table 3.

Variance Extracted Test

	Requirement Risk	Execution Risk	Client Risk	Team Risk
Requirement risk	0.586
Execution risk	0.421	0.66
Client risk	0.318	0.305	0.586
Team risk	0.49	0.618	0.489	0.666

Source: The author.

Notes: Bold elements are variance extracted estimates and draw a comparison with the off diagonal elements.

The variables were also checked for multicollinearity. Multicollinearity is detected by the presence of high bivariate correlation (>0.8) between predictive constructs or by the variance inflation factor (VIF) exceeding 4.0 (Hair et al., 2011). All bivariate correlations ranged between 0.552 and 0.7. All obtained VIF values ranged from 1.18 to 1.55, which indicates that there is no symptom of multicollinearity.

Confirmatory Factor Analysis

The measurement model was tested before proceeding to the structural model. The measurement model of software project risks consisted of variables and their associated dimensions of execution risk, requirement risk, client risk and team risk. The fit statistics GFI, and CFI for the dataset of 411 were above 0.95 which is higher than the recommended minimum value of 0.90 (Bentler, 1990; Bentler & Bonett, 1980). The root mean square error of approximation (RMSEA) was .042 and standardized root mean squared residual (SRMR) was 0.0395 well under 0.05 which is a good fit (Bagozzi & Yi, 1988).

In this study, the measurement model is a second-order factor model (Figure 2) with two higher level latent constructs—PMR and SCR (SCR)—that are proposed to govern the relationship between the four first-order constructs. The PMR construct was measured by two key underlying risk dimensions: requirement risk and execution risk. SCR was modelled as a construct that has two underlying dimensions: development team risk and client risk. The first-order measurement model served as a baseline for the second-order model.

Figure 2.

Source: The author.

The fit statistics for the second-order model were similar to the first-order model except for the chi-square value. The GFI, CFI, RMSEA and SRMR were 0.962, 0.960, 0.042 0.0404, respectively. If two models have a similar fit, the more parsimonious model is considered to be a superior one (Anderson & Gerbing, 1988).

Structural Model and Hypothesis Testing

As the overall fit of the measurement model was good, the next step was to test the structural model (Figure 3). The SEM analysis was performed using the maximum likelihood estimation procedure as it is a common choice for moderately non-normal data (Anderson & Gerbing, 1984).

Figure 3.

Source: The author.

Abbreviations: PMR = project management risk; REQ = requirement risk; EXC = execution risk; SCR = social context risk; TM- = development team risk; CL = client risk; PLN = planning; RM = risk management; PRD = product performance; PRS = process performance.

The overall fit statistics for the structural model were good with GFI and CFI values as 0.901 and 0.867, respectively. The standardized RMR and RMSEA values were 0.0546 and 0.052, respectively, also acceptable values that were slightly above 0.05.

The test results (Table 4) indicate that five of the path coefficients associated with the relationship between the latent constructs were significant at P < .05. The four insignificant paths (P > .05) were between planning and PMR, between PMR and process performance, between PMR and product performance and between process and product performance. The study results support the hypotheses H1, H2a, H2c, H5a and H5b.

The confidence interval test is also used to accept or reject hypothesis. If the value 0 does not fall within the lower and upper limits of the confidence interval, the hypothesis is accepted; otherwise, it is rejected. Considering the lower and upper limits of the confidence interval (Table 4), it is evident that the hypothesized causal relations between planning and PMR, between PMR and process performance, between PMR and product performance and between process and product performance are rejected. Hypotheses H1, H2a, H2c, H5a and H5b are accepted.

Table 4.

Standardized Regression Weights

Parameter			Estimate	Lower	Upper	P
SCR	←	PLN	–.710	–.858	–.576	.006
PMR	←	PLN	–.217	–.522	.175	.291
RM	←	PLN	.755	.628	1.003	.002
PMR	←	SCR	.811	.536	1.105	.007
PRS	←	PMR	–.204	–.493	.212	.320
PRS	←	RM	.499	.154	1.001	.026
PRD	←	PMR	–.158	–1.033	…	.528
PRD	←	RM	.777	.594	1.701	.021
PRD	←	PRS	.011	–1.849	.410	.921

Source: The author.

Table 5 summarizes the acceptance and rejection of the hypothesis based on P values and the confidence interval test.

Table 5.

Hypothesis Accepted/Rejected

No.	Hypothesis	Accepted/Rejected
H1	Social context risk will have a significant impact on project management risk PMR←SCR	Accepted
H2a	Goal identification and agreement at the planning stage will have a significant impact on social context risk SCR←PLN	Accepted
H2b	Goal identification and agreement at the planning stage will have a significant impact on project management risk PMR←PLN	Rejected
H2c	Goal identification and agreement at the planning stage will have a significant impact on risk management RM←PLN	Accepted
H3a	Project management risk will have a significant impact on process performance PRS←PMR	Rejected
H3b	Project management risk will have a significant impact on product performance PRD←PMR	Rejected
H4	Process performance will have a significant impact on product performance PRD←PRS	Rejected
H5a	Risk management will have a significant impact on process performance PRS←RM	Accepted
H5b	Risk management will have a significant impact on product performance PRD←RM	Accepted

Source: The author.

Discussion and Conclusion

This study examined two research objectives (a) what are the software development project risk dimensions and how do they influence each other and (2) how does the framework of goal-driven risk management affect the performance of a software development project? We argued that knowledge sharing to develop a shared product vision will establish a cooperative relationship among key project members and assist them in effectively identifying requirements and in project execution.

The study found that the social context risk measured by client risk and development team risk positively influences the PMR measured by requirement risk and execution risk. The results revealed that goal identification and agreement at the planning stage were associated with lowering the social context risk. Planning is the first stage of project management phases outlined by PMBOK. This study extends the literature on the effect of planning: the positive effect of planning on project performance is observed because of a reduction in risks. The study results indicated that planning has a significant positive impact on risk management. The empirical evidence has a logical appeal. With better planning, both social context risk and PMR are reduced. Planning involves decision-making on certain key issues of the project. It also ensures that the organization deploys resources to execute the project. A project has multiple stakeholders with diverse backgrounds (de Carvalho & Rabechini, 2015), unique roles, divergent expectations and vested interest in the project (Hartono et al., 2014; Saunders et al., 2015). With a shared project vision and understanding of organizational goals, team members have a common context for communication that improves the effectiveness of knowledge sharing (Lee et al., 2015) which can have a significant impact on the cost and time of a project (Pollack & Matous, 2019). Research has also shown that social relationship within the team impacts knowledge sharing (Chang et al., 2013), and these social processes are crucial for project delivery (Calamel et al., 2012).

The first activity of risk management is risk identification followed by assessment, mitigation and control. As risks reduce, fewer resources will be required to mitigate and control risks. In turn, less effort will be required for corrective actions. Hence, planning shows a positive impact on risk management. Prior studies have focused on improvement in the risk management process by means of risk checklists, frameworks and models. But not addressing social aspects of the project lead to problems (Atkinson et al., 2006; Laumer, 2011) as people are one of the biggest sources of uncertainty (Liu & Chiu, 2017). The study indicates that with a shared understanding of the project, risks reduce, thereby positively influencing risk management and project performance.

One significant observation from the study was the impact of risk on the process and product performance with planning construct. It is noted that planning does not have a direct impact on process and product performance. But planning produces a significant negative impact on project risks, that is, if goals and deliverables are identified and agreed upon by the stakeholders during the planning phase, the risks reduce. Results also indicate that the magnitude of PMR is insignificant on both process performance and product performance. If risks reduce, fewer resources will be needed to mitigate and control risks, hence less negative impact on the project budget. Also, with fewer impediments, the negative impact on the schedule will be less. Similarly, with stable, accurate requirements elicited through the shared understanding among team members, the developed technical artefact will be reliable and will meet specified quality standards, hence, improving product performance.

Although standards such as IPMA (2015) and PMBoK (2017) provide methods and techniques for risk management, they do not provide any guidance on possible interactions among risks. This is because projects are unique endeavours and to an extent experience different types of risks. Further studies have highlighted the role of top management and project team members towards project outcomes. For example, a lack of communication between top management and project team leads to risk avoidance and downplaying risks (Bhoola et al., 2014). For a project to be successful, teams responsible for its delivery need to work together effectively (Pollack & Matous, 2019). Effective risk management requires top management commitment, employee training and effective communication within and outside the organization (Dandage et al., 2018). Another study found that trust and communication quality among team members during the software tailoring process facilitate their absorptive capacity and enhance project performance (Lee et al., 2020). Although these studies have highlighted that the interconnectedness of team members leads to enhanced project outcomes, it is not clear how.

In this study, we argued that identifying goals at the early stages of the project involving key stakeholders improves project performance through risk reduction. In general, our results support the social context perspective in conceptualizing software project risks, recognizing that software systems are developed in a social context which impacts the riskiness of the project. With lower social context risks, the other risks tend to be low, resulting in better project performance.

Theoretical Contributions

By developing a framework of goal-driven risk management that can be integrated into the early phase of the project life cycle, the study makes three theoretical contributions. First, it provides project managers and researchers with a clear understanding of the consequences of goal identification and agreement on software project performance. The analysis indicates that goal identification and agreement during the planning stage reduce risks associated with software projects. The study contributes to the software project management literature by examining the effects of goal identification on different risks encountered in software projects and their interrelationship. In particular, goal identification and agreement negatively influence the social context risk which in turn reduces PMR. However, goal identification and agreement show no direct effect on PMR.

Second, the study revealed that goal identification and agreement enhance risk management by reducing risks. The finding complements the previous studies (Jiang et al., 2006; Liu & Chiu, 2017) which have indicated that a shared understanding among key stakeholders assists in identifying the scope and action plan. The findings contribute to goal setting literature in the context of software project management. The past studies (Locke & Latham, 2002) have focused extensively on how goal setting helps elaborate needs and discover inconsistent expectations. The findings of this study extend the research on goal setting by highlighting that clear goals and deliverables negatively influence project risks, thereby influencing project performance.

Third, the study revealed that the effect of process performance on product performance is insignificant, that is, the product artefact of the software project is independent of whether the system was completed within budget and within schedule. This is contrary to the findings of the study by Wallace et al. (2004) that showed a significant influence of process performance on product performance.

Implications for Practice

The study has stressed the importance of goal identification and agreement at the planning stage, highlighting that goal setting reduces the social context risk. With reduced risks, less time is spent on risk assessment, mitigation and corrective actions. So, project stakeholders need to ensure that project goals and deliverables are identified and agreed upon by all to guide the scope and action plan for the project execution.

The study also revealed that the direct impact of goal setting on PMR is insignificant. But social context risks influence PMR. To design the risk management strategy, project managers should consider this relationship between social context risk and project management risk and their implications for project performance. Project managers should use effective team management strategies to develop a cohesive relationship among client and development team members to enhance requirement elicitation and project execution.

Limitations

Like other research efforts, this study also has a few limitations. The development team and client team differ in their perspectives towards risk, risk management and success of the project because their expectations from the project are different. In this study, the relationship between risk, risk management and project performance is examined from the development team’s perspective. Further research could be carried out considering the perspectives of both development and the client team.

The study did not take into account the risk magnitude which is a product of the probability of risk and the magnitude of the loss and also that should that risk were to occur. The study only focused on risks associated with the project and did not consider possible losses due to failure. Further research could investigate whether the magnitude of potential loss influences risk perception.

Footnotes

Declaration of Conflicting Interests

The author declared no potential conflicts of interest with respect to the research, authorship and/or publication of this article.

Funding

The author received no financial support for the research, authorship and/or publication of this article.

References

Addison

, & Vallabh

(2002). Controlling software project risks: an empirical study of methods used by experienced project managers [Conference paper]. The 2002 Annual Research Conference of the South African Institute of Computer Scientists and Information Technologists on Enablement Through Technology (pp. 128–140).

Akter

, D’Ambra

, & Ray

(2011). Trustworthiness in mHealth information services: an assessment of a hierarchical model with mediating and moderating effects using partial least squares (PLS). Journal of the Association for Information Science and Technology, 62(1), 100–116.

Alberts

C. J.

, & Dorofee

A. J.

(2010). Risk management framework (No. CMU/SEI-2010-TR-017). Software Engineering Institute, Carnegie Mellon University.

Allen

, Carpenter

, Hutchins

, & Jones

(2015). Impact of risk management on project cost: An industry comparison. Journal of Information Technology & Economic Development, 6(2), 1–19.

Anderson

J. C.

, & Gerbing

D. C.

(1988). Structural equation modeling in practice: A review and recommended two-step approach. Psychological Bulletin, 103(3), 411–423.

Anderson

J. C.

, & Gerbing

D. W.

(1984). The effects of sampling error on convergence, improper solutions, and goodness-of-fit indices for maximum likelihood confirmatory factor analysis. Psychometrika, 49(2), 155–173.

Atkinson

, Crawford

, & Ward

(2006). Fundamental uncertainties in projects and the scope of project management. International Journal of Project Management, 24(8), 687–698.

Bagozzi

R. P.

, & Yi

(1988). On the evaluation of structural equation models. Journal of the Academy of Marketing Science, 16(1), 74–94.

Barber

, & Warn

(2005). Leadership in project management: from firefighter to firelighter. Management Decision, 43(7/8), 1032–1039.

10.

Barki

, Rivard

, & Talbot

(1993). Toward an assessment of software development risk. Journal of Management Information System, 10(2), 203–225.

11.

Bentler

P. M.

(1990). Comparative fit indices in structural models. Psychological Bulletin, 107(2), 238–246.

12.

Bentler

P. M.

, & Bonett

D. G.

(1980). Significant tests and goodness of fit in the analysis of covariance structure. Psychological Bulletin, 88(3), 588–606.

13.

Bentler

P. M.

, & Chou

C. P.

(1987). Practical issues in structural modeling. Sociological Methods and Research, 16(1), 78–117.

14.

Bhoola

, Hiremath

S. B.

, & Mallik

(2014). An assessment of risk response strategies practiced in software projects. Australasian Journal of Information Systems, 18(3).

15.

Boehm

(1989). Software risk management. In European Software Engineering Conference (pp. 1–19).

16.

Boehm

(1991). Software risk management: Principles and perspective. IEEE, 8(1), 32–41.

17.

Boehm

, Madachy

, & Selby

(1995). Cost models for future software life cycle processes COCOMO 2.0, Annals of Software Engineering, 1(1), 57–94.

18.

Brown

Y. F.

, Canal

, Cullen

, Elliott

, Faulkner

, Lackner

, Owens

, Peercy

, Reisz

, Tempel

, & Trellue

(2000). Software risk management: A practical guide. Department of energy quality managers software quality assurance subcommittee reference document SQAS21.01.00.

19.

Calamel

, Defélix

, Picq

, & Retour

(2012). Inter-organisational projects in French innovation clusters: The construction of collaboration. International Journal of Project Management, 30, 48–59.

20.

Carbone

T. A.

, & Tippett

D. D.

(2004). Project risk management using the project risk FMEA. Engineering Management Journal, 16(4), 28–35.

21.

Chakraborty

, Sarker

, & Sarker

(2010). An exploration into the process of requirements elicitation: A grounded approach. Journal of the association for information systems, 11(4), 212.

22.

Chang

, Yen

, Chiang

, & Parolia

(2013). Knowledge contribution in information system development teams: an empirical research from a social cognitive perspective. International Journal of Project Management, 31, 252–263.

23.

Chiang

I. R.

, & Mookerjee

V. S.

(2004). Improving software team productivity. Communications of the ACM, 47(5), 89–93.

24.

Chiocchio

, Forgues

, Paradis

, & Iordanova

(2011). Teamwork in integrated design projects: Understanding the effects of trust, conflict, and collaboration on performance. Project Management Journal, 42(6), 78–91.

25.

Conboy

, & Morgan

(2011). Beyond the customer: Opening the agile systems development process. Information and Software Technology, 53(5), 535–542.

26.

Cooke-Davies

(2002). The “real” success factors on projects. International Journal of Project Management, 20(3), 185–190.

27.

Dandage

R. V.

, Mantha

S. S.

, Rane

S. B.

, & Bhoola

(2018). Analysis of interactions among barriers in project risk management. Journal of Industrial Engineering International, 14(1), 153–169.

28.

de Carvalho

M. M.

, & Rabechini

Jr. , (2015). Impact of risk management on project performance: The importance of soft skills. International Journal of Production Research, 53(2), 321–340.

29.

Doty

D. H.

, & Glick

W. H.

(1998). Common methods bias: Does common methods variance really bias results?. Organizational Research Methods, 1, 374–406.

30.

, Keil

, Mathiassen

, Shen

, & Tiwana

(2007). Attention-shaping tools, expertise, and perceived control in IT project risk assessment. Decision Support Systems, 43(1), 269–283.

31.

Emery

F. E.

(1959). Characteristics of socio-technical systems: A critical review of theories and facts about the effects of technological change on the internal structure of work organisations; with special reference to the effects of higher mechanisation and automation. Tavistock Institute of Human Relations.

32.

Fiske

S. T.

, & Kinder

D. R.

(1981). Involvement, expertise, and schema use: Evidence from political cognition. In Nancy

& John

(Eds.), Personality, cognition and social interaction (171–190). Erlbaum.

33.

Foo

S. W.

, & Muruganatham

(2000, November). Software risk assessment model (Conference paper, Vol. 2, pp. 536–544). Proceedings of the 2000 IEEE International Conference on Management of Innovation and Technology. ICMIT 2000. Management in the 21st Century (Cat. No. 00EX457). IEEE.

34.

Fornell

, & Larcker

D. F.

(1981). Evaluating structural equation models with unobserved variables and measurement error. Journal of Marketing Research, 18(1), 39–50.

35.

Globerson

, & Zwikael

(2002). The impact of project manager on project management planning process. Project Management Journal, 33(3), 58–64.

36.

Hair

J. F.

, Ringle

C. M.

, & Sarstedt

(2011). PLS-SEM: Indeed a silver bullet. Journal of Marketing Theory and Practice, 19(2), 139–152.

37.

Han

, & Huang

(2007). An empirical analysis of risk components and performance on software projects. The Journal of Systems and Software, 80(1), 42–50.

38.

Hartono

, Sulistyo

S. R.

, Praftiwi

P. P.

, & Hasmoro

(2014). Project risk: Theoretical concepts and stakeholders’ perspectives. International Journal of Project Management, 32(3), 400–411.

39.

Hatcher

(1994). A step-by-step approach to using the SAS system for factor analysis and structural equation modelling. SAS Institute.

40.

, & King

W. R.

(2008). The role of user participation in information systems development: Implications from a meta-analysis. Journal of Management Information Systems, 25(1), 301–331.

41.

Higuera

R. P.

, & Haimes

Y. Y.

(1996). Software risk management (No. CMU/SEI-96-TR-012). Pittsburgh Software Engineering Institute, Carnegie-Mellon University.

42.

Hsu

J. S. C.

, Chu

T. H.

, Lin

T. C.

, & Lo

C. F.

(2014). Supporting virtual team building with a SS: An empirical investigation. Decision Support Systems, 34(4), 359–367.

43.

Idaszak

J. R.

, & Drasgow

(1987). A revision of job diagnostic survey: Elimination of a measurement artefact. Journal of Applied Psychology, 72(1), 69–74.

44.

Islam

, Mouratidis

, & Weippl

E. R.

(2014). An empirical study on the implementation and evaluation of a goal-driven software development risk management model. Information and Software Technology, 56(2), 117–133.

45.

Jiang

, & Klein

(2000). Software development risks to project effectiveness. The Journal of Systems and Software, 52(1), 3–10.

46.

Jiang

J. J.

, Klein

, & Chen

H. G.

(2006). The effects of user partnering and user nonsupport on project performance. Journal of the Association for Information Systems, 7(1), 68–90.

47.

Jiang

J. J.

, Klein

, & Discenza

(2002). Perception differences of software success: Provider and user views of system metrics. Journal of systems and software, 63(1), 17–27.

48.

Jiang

J. J.

, Klein

, & Ellis

T. S.

(2002). A measure of software development risk. Project Management Journal, 33(3), 30–41.

49.

, & Zhang

(2011). Effects of empowerment on performance in open-source software projects. IEEE Transactions on Engineering Management, 58(2), 334–346.

50.

Keil

, Cule

, Lyytinen

, & Schmidt

(1998). A framework for identifying software project risks. Communications of the ACM, 41(11), 76–83.

51.

Keil

, Rai

, & Liu

(2013). How user risk and requirements risk moderate the effects of formal and informal control on the process performance of IT projects. European Journal of Information Systems, 22(6), 650–672.

52.

Keil

, Rai

Mann

J. E. C.

, & Zhang

G. P.

(2003). Why software projects escalate: The importance of project management constructs. IEEE Transactions on Engineering Management, 50(3), 251–261.

53.

Klein

, & Jiang

J. J.

(2001). Seeking consonance in information systems. Journal of Systems and Software, 56(2), 195–202.

54.

Kontio

(2001). Software engineering risk management: A method, improvement framework, and empirical evaluation [Unpublished doctoral dissertation]. Helsinki University of Technology.

55.

Krosnick

J. A.

(1991). Response strategies for coping with the cognitive demands of attitude measures in surveys. Applied Cognitive Psychology, 5(3), 213–236.

56.

Krosnick

J. A.

(1999). Survey research. Annual Review of Psychology, 50, 537–567.

57.

Krosnick

J. A.

, & Alwin

D. F.

(1987). An evaluation of a cognitive theory of response-order effects in survey measurement. Public Opinion Quarterly, 51(2), 201–219.

58.

Kutsch

(2008). The influence of intervening conditions on the over and underestimation of risk. International Journal of Managing Projects in Business, 1(4), 602–610.

59.

Lamsweerde

A. V.

(2000). Requirements engineering in the year 00: A research perspective (Conference paper, pp. 5–19). Invited Keynote Paper, Proceedings of 22nd International Conference on Software Engineering.

60.

Lapouchnian

(2005). Goal oriented requirements engineering: An overview of current research [Symposium, pp. 249–263]. Proceedings RE’01, 5th IEEE International Symposium on Requirements Engineering, Toronto.

61.

Larson

(1997). Partnering on construction projects: A study of the relationship between partnering activities and project success. IEEE Transactions on Engineering Management, 44(2), 188–195.

62.

Laumer

(2011). Why do people reject technologies – a literature-based discussion of the phenomena “resistance to change” [Conference paper]. ECIS 2011 Proceedings of the Information Systems and Managerial Psychology Research.

63.

Lee

, Chou

, & Chen

(2020). The effect of process tailoring on software project performance: The role of team absorptive capacity and its knowledge-based enablers. Information Systems Journal, 31, 120–147.

64.

Lee

, Park

, & Lee

(2015). Raising team social capital with knowledge and communication in information systems development projects. International Journal of Project Management, 33, 797–807.

65.

Letier

(2001). Reasoning about agents in goal-oriented requirements engineering [PhD. thesis]. University of Louvain.

66.

Lim

C. S.

, & Mohamed

M. Z.

(1999). Criteria of project success: An exploratory re-examination. International Journal of Project Management, 17(4), 243–248.

67.

Liu

G. H.

, Wang

E. T.

, & Chua

C. E. H.

(2015). Leveraging social capital to obtain top management support in complex, cross-functional IT projects. Journals of the Association for Information Systems, 16(1), Article 1.

68.

Liu

J. Y.

, & Chiu

G. C.

(2017). Influence of project partnering on stakeholder role ambiguity and project manager risk perception in information systems project. Project Management Journal, 47(6), 94–110.

69.

Liu

J. Y. C.

, Chiang

J. C.

, Yang

M. H.

, & Klein

(2011). Partnering effects on user-developer conflict and role ambiguity in information system projects. Information and Software Technology, 53(7), 722–729.

70.

Locke

E. A.

, & Latham

G. P.

(2002). Building a practically useful theory of goal setting and task motivation: A 35-year odyssey. American psychologist, 57(9), 705–717.

71.

Maguire

, & Redman

(2007). The role of human resource management in information systems development. Management Decision, 45(2), 252–264.

72.

Manalif

(2013). Fuzzy expert-COCOMO risk assessment and effort contingency model in software project management [Electronic thesis and dissertation repository].

73.

Maruping

L. M.

, Zhang

, & Venkatesh

(2009). Role of collective ownership and coding standards in coordinating expertise in software project teams. European Journal of Information Systems, 18(4), 355–371.

74.

McFarlan

(1982). Portfolio approach to information-systems. Journal of Systems Management, 33(1), 12–19.

75.

Mitchell

V. L.

(2006). Knowledge integration and information technology project performance. Mis Quarterly, 30(4), 919–939.

76.

Nakatsu

R. T.

, & Iacovou

(2009). Comparative study of important risk factors involved in offshore and domestic outsourcing of software development projects: A two-panel Delphi study. Information & Management, 46(1), 57–68.

77.

NASSCOM. (2017, June 15). The IT-BPM industry in India 2017: Strategic review. http://www.nasscom.in/knowledge-center/publications/it-bpm-industry-india-2017-strategic-review

78.

Nelson

R. R.

, & Jansen

K. J.

(2007). IT project management: infamous failures, classic mistakes, and best practices. MIS Quarterly Executive, 6(2), 67–78.

79.

Nelson

R. R.

, & Morris

M. G.

(2014). IT project estimation: Contemporary practices and management guidelines. MIS Quarterly Executive, 13(1), 15–30.

80.

Nidumolu

S. R.

(1996). Standardization, requirements uncertainty and software project performance. Information & Management, 31(3), 135–150.

81.

Patnayakuni

, Rai

, & Tiwana

(2007). Systems development process improvement: A knowledge integration perspective. IEEE Transactions on Engineering Management, 54(2), 286–300.

82.

Pava

C. H.

(1983). Designing managerial and professional work for high performance: A sociotechnical approach. Global Business and Organizational Excellence, 2(2), 126–135.

83.

Pollack

, & Adler

(2015). Does project management affect business productivity. Project Management Journal, 45(6), 17–24.

84.

Pollack

, & Matous

(2019). Testing the impact of targeted team building on project team communication using social network analysis. International Journal of Project Management, 37(3), 473–484.

85.

Podsakoff

P. M.

, MacKenzie

S. B.

, & Podsakoff

N. P.

(2003). Common method bias in behavioural research: A critical review of the literature and recommended remedies. Journal of Applied Psychology, 88(5), 879–903.

86.

Podsakoff

P. M.

, MacKenzie

S. B.

, & Podsakoff

N. P.

(2012). Sources of method bias in social science research and recommendations on how to control it. Annual Review of Psychology, 63, 539–569.

87.

Procaccino

J. D.

, Verner

J. M.

, Overmyer

S. P.

, & Darter

M. E.

(2002). Case study: Factors for early prediction of software development success. Information and Software Techology, 44(1), 53–62.

88.

Project Management Institute. (2013). Organizational project management maturity model (OPM3): Knowledge foundation. Author.

89.

Project Management Institute. (2014). The high cost of low performance. PMI pulse of the profession. Author.

90.

Project Management Institute. (2017). Project management body of knowledge (6th ed.). Author.

91.

Purvis

, Henry

R. M.

, Tams

, Grover

, McGregor

J. D.

, & Davis

(2016). The impact or residual risk and resultant problems on information system development project performance. Project Management Journal, 47(4), 51–67.

92.

Qureshi

, & Fang

(2011). Socialization in open source software projects: A growth mixture modeling approach. Organizational Research Methods, 14(1), 208–238.

93.

Sarker

, Ahuja

, Sarker

, & Kirkeby

(2011). The role of communication and trust in global virtual teams: A social network perspective. Journal of Management Information Systems, 28(1), 273–310.

94.

Sarker

, & Sarker

(2009). Exploring agility in distributed information systems development teams: An interpretive study in an offshoring context. Information Systems Research, 20(3), 440–461.

95.

Sato

, & Hirao

(2013). Optimum budget allocation method for projects with critical risks. International Journal of Project Management, 31(1), 126–135.

96.

Sauer

, Gemino

, & Reich

B. H.

(2007). The impact of size and volatility on IT project performance. Communications of the ACM, 50(11), 79–84.

97.

Saunders

F. C.

, Gale

A. W.

, & Sherry

A. H.

(2015). Conceptualising uncertainty in safety-critical projects: A practitioner perspective. International Journal of Project Management, 33(2), 467–478.

98.

Schmidt

, Lyytinen

, Keil

, & Cule

(2001). Identifying software project risks: An international Delphi study. Journal of Management Information Systems, 17(4), 5–36.

99.

Schwarz

, Hippler

, & Noelle-Neumann

(1992). A cognitive model of response-order effects in survey measurement. In Norbert

& Seymour

(Eds.), Context effects in social and psychological research. Springer-Verlag.

100.

Sethi

, & Iqbal

(2008). Stage-gate controls, learning failure, and adverse effect on novel new products. Journal of Marketing, 72(1), 118–134.

101.

Sharma

, Sengupta

, & Gupta

(2011). Exploring risk dimensions in Indian software industry. Project Management Journal, 42(5), 78–91.

102.

The Standish Group. (2016). Standish group chaos report. https://www.standishgroup.com/outline

103.

Teller

, Kock

, & Gemunden

H. G.

(2014). Risk management in project portfolios is more than managing project risks. Project Management Journal, 45(4), 67–80.

104.

Trist

E. L.

(1981). The evolution of socio-technical systems (Vol. 2). Ontario Quality of Working Life Centre.

105.

Turner

, & Zolin

(2012). Forecasting success on large projects: Developing reliable scales to predict multiple perspectives by multiple stakeholders over multiple time frames. Project Management Journal, 43(5), 87–99.

106.

Verner

J. M.

, & Evanco

W. M.

(2005). In-house software development: What project management practices lead to success? IEEE Software, 22(1), 86–93.

107.

Wallace

, Keil

, & Rai

(2004). How software project risk affects project performance: An investigation of the dimensions of risk and an exploratory model. Decision Science, 35(2), 289–321.

108.

Whittaker

(1999). What went wrong? Unsuccessful information technology projects. Information Management & Computer Security, 7(1), 23–30.

109.

Wienclaw

(2014). Information system project management. EBSCO research starters. Great Neck Publishing.

110.

, Olson

D. L.

, & Dolgui

(2015). Decision making in enterprise risk management: A review and introduction to special issue. Omega, 57, 1–4.

111.

Zmud

R. W.

(1980). Management of large software development efforts. MIS Quarterly, 4, 45–55.

112.

Zwikael

, & Sadeh

(2007). Planning effort as an effective risk management tool. Journal of Operations Management, 25(4), 755–767.