Microsoft Word - AJIS_18(3)_v10.docx Australasian Journal of Information Systems Volume 18 Number 3 2014 161 AN ASSESSMENT OF RISK RESPONSE STRATEGIES PRACTICED IN SOFTWARE PROJECTS Vanita Bhoola S. P. Jain Institute of Management and Research India vanita@spjimr.org S B Hiremath National Institute of Industrial Engineering India hiremat.nitie@gmail.com Debasis Mallik S. P. Jain Institute of Management and Research India debasis.mallik@spjimr.org ABSTRACT Risk management and success in projects are highly intertwined – better approaches to project risk management tend to increase chances of project success in terms of achieving scope & quality, schedule and cost targets. The process of responding to risk factors during a project’s life cycle is a crucial aspect of risk management referred to as risk response strategies, in this paper. The current research explores the status of risk response strategies applied in the software development projects in India. India provides a young IT-savvy English-speaking population, which is also cost effective. Other than the workforce, the environment for implementation of software projects in India is different from the matured economies. Risk management process is a commonly discussed theme, though its implementation in practice has a huge scope for improvement in India. The paper talks about four fundamental treatments to risk response – Avoidance, Transference, Mitigation and Acceptance (ATMA). From a primary data of 302 project managers, the paper attempts to address the risk response factors that lead to successful achievement of project scope & quality, schedule and cost targets, by using a series of regressions followed with Seemingly Unrelated Regression Equations (SURE) modelling. Mitigation emerged as the most significant risk response strategy to achieve project targets. Acceptance, transference, and avoidance of risk were mostly manifested in the forms of transparency in communication across stakeholders, careful study of the nature of risks and close coordination between project team, customers/end-users and top management. Keywords: Project Risk Management; Risk response strategies; Software Projects INTRODUCTION Information Technology (IT) projects have inherent risks, some of which can be managed to an acceptable level (Kwak & Stoddard, 2004). Implementation of an IT project is a double edged sword – on one hand, it can give tremendous opportunities to gain revenues, and on the other, it can pose a threat to both the IT service provider and also the customer (Chandra & Calderon, 2009). Though there is abundance of research in the area of IT project risk management, there is serious dearth of such studies in the Indian context (Thomas & Bhasi, 2011). Australasian Journal of Information Systems Volume 18 Number 3 2014 162 The National Association of Software and Services Companies (NASSCOM), a trade association of Indian Information Technology and Business Process Management (IT-BPM) industry, predicts that the industry expenditure is expected to grow by 6 percent in 2013-14 and to touch USD 2 trillion, in the next couple of years. Information Technology (IT) and Information Technology Enabled Services (ITES) provide about 7.5 percent of the Indian GDP and expected to increase by another 2 percent in the coming years (NASSCOM, 2013). On one hand, this portrays a unique opportunity for major IT companies in India to capitalize on this, and on the other, it triggers an alarm on a major source of threat, which many Indian IT firms are blissfully unaware or tend to oversee – the associated risk. The purpose of this paper is to understand risk response strategies in software projects in India and the factors that determine them. Based on primary study, data was collected from 302 software project managers and project leads on risks factors and its risk solutions which influence project outcomes. In other words, the focus of this empirical study is on risk response strategies that are practiced to alleviate these risks and its implications on achieving scope & quality, schedule and cost targets. Four major forms of risk response strategies are considered - Avoidance, Transference, Mitigation and Acceptance. The findings of the study open a new dimension of looking at risk response strategies to deal with scope & quality, schedule and cost targets. As the respondents of the study are practitioners in the area of software development projects, the different forms of application of risk response strategy adopted in diversified scenarios, is a significant contribution of the current research. Software project risk management Software development projects have a dismal track-record of cost and schedule overruns and quality and usability problems (Kwak & Stoddard, 2004). The focus of Kwak & Stoddard (2004) is on project risk management by creating an organizational environment and culture which is conducive. In similar lines, Doherty & King (2003) and Warkentin & Willison (2009) discuss how organizational risks stemming from organizational culture, structure and business processes impact technical software development issues, creating a wide range of potential trouble points. A study revealed that 65 per cent of the project failures were due to management issues (Mcmanus, 2004). Alter & Ginzberg (1978) focused on problems associated with the organizational acceptance and implementation of the information system. They argued that implementing any system would involve uncertainty from the managerial point of view. While the focus of the abovementioned papers has been on organizational issues that influence project risks, other factors such as those which are project specific, human resource related or associated with the overall environment in which the project is to be implemented are ignored. Apparently, this implies that software project development is a tightrope walk. Therefore, managing risks with a holistic perspective is of primary importance in software project development, especially in the case of long duration software projects (Yong et al., 2006). Boehm's model (1991) suggests a comprehensive set of steps and guidelines to manage software development risks. For each of the top 10 risk items, Boehm developed a set of risk-management techniques. These risk management practices include award-fee contracts, benchmarking, contracts, design to cost, early user's manuals, incremental development, information hiding, instrumentation, mission analysis, morale building, pre-award audits, pre-scheduling, prototyping, requirements scrubbing, software re-use, team building, tuning, user surveys, compatibility analysis, competitive design, cost-benefit analysis, cross-training, detailed multisource cost and schedule estimation, inspections, job-matching, modeling, organizational analysis, reference checking, scenarios, simulation, staffing with top talent, task analysis, technical analysis and user characterization. Having said that, the model does not allow for continuous improvement of project performance, through updating changing risk profiles in software projects. Davis' model (1982) is based on the basic premise that projects often use inappropriate methodologies for obtaining and documenting user requirements. Hence, he suggests “packaging” different methods into alternative strategies, which can be then linked to risk management model. These strategies include Australasian Journal of Information Systems Volume 18 Number 3 2014 163 asking from users, deriving from existing systems, synthesis from characteristics of the utilizing system and discovering from experimentation. Established software companies dealing with projects would, by contrast, have effective systems and methods for procurement and documentation of clients’ requirements. Cavusgil & Sikora (1988) discuss reactive and proactive strategies for countering gray market channels. While reactive approach can help project managers and organizations to prevent repetition, proactive risk management has to be more useful as it focuses on the minimization of the likelihood of the emergence of a risk factor, instead of waiting for its occurrence. Focusing mostly on large long-term projects, Pavlak (2004) discusses the importance of maintaining a balance between reactive and proactive risk management strategies in projects. In similar lines, Alter & Ginzberg (1978) recognized and classified several risk resolution strategies into inhibiting or compensating strategies. Inhibiting strategies are ex ante while compensating strategies are ex post. McFarlan (1982) classified risk resolution techniques into four types, namely external integration, internal integration, formal planning and formal control mechanisms. This simplified outlook of classifying risks primarily focuses on organizational or corporate culture and planning and control mechanisms, largely ignoring the greater challenges of risk response strategies developed by later authors like Abdul-Rahman et al., (2012). Rivard et al., (2011) discusses the relevance of estimating risk exposure. It implies assessing the loss associated with a deviation from each of the project’s objectives and the probability of occurrence of each of these undesirable outcomes, hence estimating risks in the beginning of the projects will help mitigating risks. An extended discussion on identification of risk and strategies to overcome such risks would have further strengthened the research. In the above literature we have observed the diversified approaches used by researchers in developing risk management practices in software projects. One of the key elements of risk management is controlling these risks with appropriate response strategies. The next sections discuss these aspects of risk management. Project failure and dynamic risk management Keil et al., (2013) documents that IT/IS projects are mired with problems related to poor process performance, budget spillovers and cost overruns. According to the authors, exercising formal and informal monitors and controls or identifying and managing key risks can help prevent project failures, but the authors admit that there are no full-proof mechanisms to ensure project success. Keil et al., (1998) asserts that too many software projects end up in failure. Hence, identifying and countering the threats to failure, is the key to success. According to Wallace et al., (2004) the inability to identify and understand the depth and breadth of inherent project risks and respond to them accordingly, is a major cause of project failures. Abdul-Rahman et al., (2012) identifies risk uncertainties as the major causes to software project failures, which generally manifest in the form of cost and time overruns. Though failure is majorly identified from risk uncertainties and manifest in the form of cost and time overruns, the process of alleviation of such risks lacks empirical evidence. Drummond, H. (2005) studies a small business to discuss the concept of “entrapment” of organizations in not embracing change as a part of organizational development. Complacency to restore existing gains, risk aversion, myopic vision, ego-defensiveness and social pressures are some of the attitudinal deficiencies, discussed by Drummond (2005), the restrain organizations to achieve sustainability and growth. Schmidt, et al., (2001) disclose the sad state of affairs of software projects, internationally. According to the authors 25 percent of all software projects are cancelled outright, 80 percent of all software Australasian Journal of Information Systems Volume 18 Number 3 2014 164 projects encounter cost overruns and 75 percent of large systems are operational failures. Hence, the sticking point here is to identify and control risk occurrence (Boehm, 1989; Karolak, 1996). Lehtinen et al., (2014) study the causes for software project failures and their interconnectedness. Using a root cause analysis, the reasons for project failure were detected. Lack of cooperation, collaboration and communication, task backlogs and lack of software testing resources were some of the common causes across tasks, people and processes that were responsible for project failures. The nature of IT/software risks is often dynamic in nature. To develop a comprehensive risk management plan based on past data and information, often repeated occurrences to risks are unavailable. Hence, risk assessment on a current project is mostly based on soft data, rather than hard data from historical experiences (Gasparini, et al., 2004). Even then, the company will surely make an attempt to counter risks by taking preventive actions through thorough assessments on a dynamic basis across phases of the project life cycle. This leads to a process of dynamic risk control using preventive steps and assessment, in an iterative manner (Gasparini, et al., 2004). An example of a dynamic risk management loop, in the form of re-scoping loop of assessment, has been provided by the authors as given in figure 1. Figure: 1: Dynamic Risk Management Loop (Gasparini, et al., 2004) Dynamic risk control typically has the rescoring and the prevention loop. The job of the preventive loop is to change the future course of action of the perceived risks, based on the changed scenario and subjective risk assessment. Iterative exercises performed by the project team to identify new risks, assess and monitor, reassess and perform the same process throughout the project life cycle is an important component of dynamic risk management. The paper, built on Bayesian approach, is theoretical. The paper fails to illustrate how the procedure can be implemented over multiple projects with diversified complications. In the context of software project management, there is serious dearth of research in dynamic risk management. The reasons for the same could be two-fold. Duration of software projects is generally short. Hence, the iterative process of learning from previous mistakes, identifying new risks and providing new set of risk response strategies is not very relevant. Effective planning, continuous monitoring and timely implementation are often the keys to success. With the advent of agile methodologies, software projects can now face dynamic business risks and changing clients’ requirements more effectively (Augustine et al., 2005). Hence, the scope of the current research is static risk management and not an iterative process of implementing changes through learning from previous mistakes within the same project life cycle. This necessitated the creation of a comprehensive and exhaustive list encompassing all the risk response strategies as discussed in the previous sections. Australasian Journal of Information Systems Volume 18 Number 3 2014 165 Risk response strategies The success of the Information Technology (IT) projects is influenced by various factors like customer involvement, schedules and budgets, flexible project tools, and a positive attitude towards project success (Pieterse, 2012). Agarwal & Rathod (2006) find that the performance of internal stakeholders is the most significant determinants of project success. They propose that the cost, time and scope (software functionality and quality combined) are the parameters that signify the internal characteristics of the process adopted in software projects. The study, as it appears, depends on a purposive sample, rather than a random sample and limits the evaluation of project success indicators from the standpoint of cost, time and scope. March & Shapira (1987) study the variability in the outcome of project success in the context of decision makers’ attitudes to risk aversion. The authors suggest greater the variance involved, higher should be the return on investment, and vice versa. The paper does not discuss the complications involved in risk identification and the factors that lead to high diversity leading to changing patterns on risk solutions. Investing on high risk projects with high returns is acceptable, provided risk calculations are in place, explicitly (Armour, 2005). Managerial issues related to risk response strategies therefore appears to be more critical than technical issues (Abdul-Rahman et al., 2012). Fairley & Willshire (2005) coined the term ‘risk handling’ that implies a course of action taken in response to risk factors that includes risk acceptance, risk avoidance, risk transfer and risk mitigation. The study defines risk response strategies which are categorized as: avoidance, transference, mitigation and acceptance. Once risks associated in a project are identified, a proper risk response strategy has to be formulated and be made accountable for implementation. Each of these responses to the identified risk would require a responsible owner. Risk response is decided based on the risk category, proximity, probability, frequency and impact on the project (Hillson, 2002, PMBOK®, 2013; Salmeron & Lopez, 2012; Tesch et al., 2007). Identification of risks alone cannot ensure project success. Implementation of risk response strategies is crucial to meeting project targets. Using integer programming model, Zhang & Fan (2014) propose a novel method for selecting the right risk response strategy in an iterative manner. Risk response strategies, in this study, are broadly classified into four categories namely, avoidance, transference, mitigation and acceptance. The study could have been further enriched by considering the contribution of human elements like, attitudes, incentives, experiences, etc. It also considers the occurrence or non- occurrence of each risk element independent of the other risks. Fairley (2005) states that risk handling includes all the four types of risk response strategies namely, avoidance, transference, mitigation and acceptance. Fairley (2005) suggests that selection of a particular response to risk should always be a strategic decision. The next sections discuss each of these in greater detail. Avoidance Eliminating activities with a high probability of loss by making it difficult for risk to occur, or by executing the project in a different way which will achieve the same objectives but which insulates the project from the effect of the risk can be termed was risk avoidance. A snapshot of risk avoidance variables is given below. Communication between project head and management is crucial to the successful implementation of project. This is generally influenced by the principal–agent relationship between the parties and the contract type chosen (Müller & Turner, 2005). Bond-Barnard et al., (2013) show that a balance between formal and informal communication between project manager and other stakeholders reduces mistrust Australasian Journal of Information Systems Volume 18 Number 3 2014 166 and conflict of interest. A study conducted by Fisher & Urich (1999) introduces the models of instrumental and transformative participation and the way they influence flow and communication between project manager and other stakeholders. Rosenkranz et al., (2013) argues that knowledge transfer, communication, and shared understanding between project stakeholders are important requirements to projects. The ability of the project manager to facilitate communication among stakeholders, create the desired commitment level and reduce uncertainty can help avoiding the risk of project failure (Burström & Jacobsson, 2011). Blackstone et al., (2009) points out the importance of project managers’ skills and leadership capabilities, user involvement, top management commitment and organizational engagement in successful implementation of projects. Shiferaw et al., (2012) find that weak links between project stakeholders affect the effectiveness of project governance system. Laursen (2011) asserts that there are often weak links that exist between what is known by the staff as “ordinary problems” of organizations and the objectives and goals of the project. Though these studies discuss about the weak links they fail to consider the softer issues related to attitude towards work, personality traits, motivating factors, interpersonal conflicts, etc. and its impact on project stakeholders. While investigating the role of phased project planning in project success, Tasevska et al., (2014) study four measures namely, business case development, scope planning, baseline plan development and risk planning. Kutsch et al., (2011) state that among many reasons behind project failure, ‘planning fallacy’, i.e., over-optimism in the planning phase in the project due to resource misallocation and miscommunication is crucial. It is preferable if a project is budgeted, one phase at a time, instead of budgeting at a time. Khamooshi & Cioffi (2013) develop a model for phase-wise project budgeting and scheduling under uncertainty. Conversely, projects which involve cross-cultural teams working together from remote locations often require an overall plan and budget which is implemented through intertwining of phase-wise planning and budgeting. Keil et al. (1998) discusses the importance of contingency plans that constitutes a serious threat to the successful completion of a software development project. Thal & Martínez (2011) suggest that contingency plans help project teams to deal with uncertainties such as, handling new product development, enforcing innovative actions, increase plan flexibility, etc. Hanisch & Wald (2012) studies 1,622 articles and present a meta-analysis of project contingency theory as appears in project management journals. A comparative analysis of the significance of contingency planning vis-à-vis ex ante and ex post risk management, is however, lacking. Several projects use a preliminary feasibility study to facilitate the analysis of Go/No Go decision- making processes (Sungmin & Caldas, 2009). Alkass et al., (2006) appraise that feasibility study can help in selecting the best alternative during the strategic planning phase of a project, more so before the starting the project life cycle. Quartel et al., (2012) use an architecture-based approach to IT software project evaluation. The approach offers organizations an instrument to assess the business value of a project in terms of its contribution to a selected set of business goals. Software industry is heavily technology-driven and hence, changes and upgrades frequently. A pilot run is often conducted to appreciate whether the investment on a new technology is worth (Cardenas et al., 2014). Though running a pilot survey is gratifying in exploratory research, it is often a costly affair and does not provide a true platform to ensure successful implementation of software. Continuously meeting on agreed customers’ requirements at the lowest cost, without sacrificing on quality and other deadlines, after realizing the potential of the existing team members and the support from organization, has its inherent risks (Scurr, 1990). Abd et al., (2014) finds that companies often Australasian Journal of Information Systems Volume 18 Number 3 2014 167 employ flexible manufacturing systems (FMS) capable of dealing with unexpected events and constantly changing customer expectations. The implementation of agile methods can often be a precursor to employing FMS in software projects can be difficult. Performing an in-depth analysis of the risks associated with assignment of roles and responsibilities of key stakeholders that includes project team members, clients, consultants, and contractors can avoid project failure (Doloi, 2013). A roles and responsibility assignment matrix including the participation of all concerned stakeholders is useful (Melnic & Puiu, 2011). Tesch et al. (2007) suggest that the keys to managing risks at each stage of the project are to assign an experienced project manager skilled in change management and monitoring progress. This can act as an avoidance strategy to provide risk solutions. Parker et al. (2013) states that the high failure rate of change interventions suggests that improvements are required in terms of better management, monitoring and control. Transference Transferring a portion or entire risk to a third party, by identifying another stakeholder to manage the risk activities with low probability of recurrence, but with a large financial impact, is termed as risk transference. This section discusses the various variables and their reference to literature with risk transference. Project failures highlight the importance of measuring, understanding and managing risks. Identification of the sources of risks and breakdowns in detecting risks can provide significant clues to project failures (Eicher & Ruder, 2007). Identifying the root cause and detecting the sources of risk can help in risk transference in an efficient manner. Byoun et al., (2013) finds that more leverage is used when project risk is high and projects use less leverage in the presence of risk-reducing features including off-take agreements. There are a set of attributes that ensures the presence of risk in different phases of the project based on changes in the external environment, cost reduction attributes, etc. (Zavadskas et al., (2010). A detailed knowledge sharing on the nature of the risks identified and evaluated, can enable shifting risks to another phase of the project to avoid delays, cost overruns, change orders and avoid design omissions and errors from unforeseen contingencies (Rodriguez et al., 2010). This runs the risk of not mitigating it at the source and transferring it to another phase where the degree of risk may escalate or change its form. Chan and Au (2007), in this context, argues that when risk is transferred there is generally a time overrun in the project, as the team members and the nature of job in changed phase could be different. When it is possible to shift risk after taking a well-thought-after decision and clearly communicating the impact to the possible stakeholders, mitigating risk is faster and smoother (Zofi, 2012). When risk transfer is not smooth and adequately disclosed, mismatch in the expectations of related parties may lead to the emergence of new risks. These risks need to be examined and evaluated for cost effective risk management plans (Golden et al., 2007). Skyner (2006) discusses the requirement of balance that is to be maintained between risk transference and risk mitigation. It is not necessary that effective functioning of the prior smoothly leads to the later. With the presence of unclear regulations, lack of transparency, changing market conditions and lack of proper communication between stakeholders, transference of risk may create problems in mitigation (Rosenbaum, 2005). Often risks originating from external environmental factors like natural hazards or war are transferred to the end users or customers in the form of time or cost overruns. This can lead to mismatch of expectations between stakeholders, thereby leading to the creation of a new set of risks (Golden, et al., Australasian Journal of Information Systems Volume 18 Number 3 2014 168 2007). Evolution of such new risks must be examined and evaluated as a part of ascertaining cost effective risk management plans. Mouraviev & Kakabadse (2014) discuss risk transference from the point of view of public private partnership (in short, PPP). They argue that even when the transference is smooth, the cost and time involved in such process are often extensive and the governments’ financial outlays are seriously compromised. Armstrong & Paolucci (2010) argue that risk transfers within a project improve efficiency, if it is a well-thought-after decision with mutual agreement, knowledge transfer and communication. Risk transfer and delivery efficiency of the party or project phase to which risk has been transferred go hand in hand (Witt & Liias, 2011). The papers discuss risk transfer from the viewpoint of sectors like insurance and construction in the context of PPP. Hence, the applicability of the arguments in favor of risk transference is yet to be tested for the IT sector. Mitigation Reducing the risk in order to make it more acceptable to the project or organization, by reducing its impact can be termed as mitigation of risk. Tesch et al., (2007) identify several mitigation strategies as risk response solutions. As a mitigation strategy the authors suggest escalating risk issues to top management, obtain signoff on commitments and stop the project and discuss with sponsor and management on further steps. In case there is lack of commitment from the management or the customer, the authors also suggest working with them to understand the reasons for indifference. Laurentiu & Gabriela (2013) discuss the importance of a cost-benefit analysis on existing risks in the project. The authors suggest using a sensitivity analysis to identify risk parameters that may impact during project development and operational period and may lead to failure and varied points in the project life cycle. Funding plays a crucial role to conduct risk mitigation activities and enabling the system to restore its usual functioning (Hecker, 2002). Funding deficits are an integral part of cost of time overruns. Infrastructure projects are prone to more funding deficits than projects in manufacturing or even software sectors (Little, 2010). Such funding deficits are more prevalent in large infrastructure or multihazard mitigation projects with where investment stakes are high. According to Vizard (2008) IT firms have enough funding for their ongoing projects, but lack funding for infrastructure required for business continuity. According to Goble & Bier (2013) periodic communication of risk assessment results can mitigate risks in projects. According to the authors risk assessments are repositories of structured information and a medium for communication. Hence, the judicious use of risk assessment tools with adequate communication can mitigate risks to a great extent (Veil & Husted, 2012). Alexandra-Mihaela & Danut (2013) point out that internal communication is one of the most important factors for success in project management. Project manager should tract the internal communication to ensure project deliverables to make ends meet (Aubry, 2011). An effective project team’s skills, experience motivation and teamwork are enhanced with a proactive and supportive management (Bagdonien , 2012). The significance of proper communication between stakeholders has been discussed by various researchers from the viewpoints of different risk response strategies. From the perspective of risk mitigation, internal communication within project team and immediate stakeholders within the organization commands more relevance. Having said that, this does not undermine the significance of periodic review meetings with clients and customers to enhance risk mitigation (Swink, 1996). As the nature of project complexity and scope are different, different processes or more strict and extensive use of well-known practices are required with specific tools and techniques (Besner & Hobbs, Australasian Journal of Information Systems Volume 18 Number 3 2014 169 2008). According to Bolles et al., (2006) project management requires total commitment and support of executive management and strict adherence to documented processes. Project success and client satisfaction are results of collaborative actions by project actors throughout its life cycle. Hence, risk mitigation is effectively conducted if all changes are discussed with both customers and top management (Holzmann & Panizel, 2013). The focus of the paper revolves around communications management in agile software development projects and not managing risks using diversified response strategies. Acceptance Recognizing that residual risks (i.e., risk that remains after a risk response has been taken) will exist and responding either actively by allocating appropriate contingency, or passively doing nothing except monitoring the status of the risk can be termed as risk acceptance. Johnstone (2000) identifies three strategies to ensure effective evaluation and acceptance of risk factors. These strategies are as follows: firstly, screening all stakeholders based on their risk profile; secondly, stringency of reporting standards; and lastly, more proactively using risk adaptation strategies. Discussing on software project risk management, McManus (2003) points out that if risk is evaluated and acknowledged, risk planning is easier. Risk acceptance would also mean that taking no action on risk was a carefully thought-after decision. Hence, if a decision is taken not to take any action of the existing risk and to accept it the way it is, it can be termed as risk acceptance strategy (Fairley, 2005). Risk acceptance can act as a double-edged sword, if not monitored and inspected by senior management. It can become a potential threat to organizations if it crosses a predetermined threshold level, thereby raising other forms of risks. According to Sang-Hoon & Elsaid (1985), risk evaluation of a project is an examination process of whether the positive Net Present Value (NPV) estimate provides a large enough safely margin to compensate for the uncertainties with its estimated cash flows. Yelin et al., (2012) designed a practical and computerized risk evaluation model where a risk hierarchy structure composed of 17 weighted risk factors are developed. The risk evaluation model is then developed using a fuzzy synthetic evaluation approach. Despite the availability and practice of such sophisticated risk identification, assessment methodologies and response strategies, projects fail. This can be partly because of the gap between theoretical foundations of risk management and its practical implementation and partly because of the organizational approach to risks. Unless the attitude to risk response follows a top down approach with management supervision, implementation at the project level often fails, despite the availability of several control mechanisms to achieve targets. Berkel (2014) analyses that risk evaluation and monitoring process are often seen as administrative burden by project team members. Quadruple targets Software projects are often entangled with constraints. A good project manager should be able to balance his resource requirements and plan his work procedures effectively to ensure achievement of scope & quality, schedule and cost targets to encounter risks (Samáková, 2013). Achieving scope & quality, schedule and cost targets are the major goals for successful implementation of projects. While the triple targets of scope, time, and cost were the major objectives to be achieved to meet the goals of the projects, at the same time, the delivery of quality product to the client cannot be ignored (Pinto & Mantel, 1990). By contrast, Thakurta (2013) considers quality delivery of a project to be one of the most important determinants of project success. Scope creep directly impacts the project quality. Improper scope Australasian Journal of Information Systems Volume 18 Number 3 2014 170 planning or identifying requirements leads to scope creep, which, in turn, can adversely impact project quality, e.g., high severity defects resulting in deterioration of product quality (Ferreira et al., 2009). A project is considered successful if it achieves its business objective, within the defined scope of work, agreed upon schedule and cost budgets and with acceptable quality. Project management is performed to achieve these objectives by managing various aspects of the project such as scope, time, cost, quality, human resources, organizational culture, communications, and procurement management in an integrated manner (Mir & Pinnington, 2014). Most researchers concentrate on the impact of software risk management on achieving the quadruple targets of scope & quality, schedule and cost. A closer look into the quadruple targets is given below. Scope: Project scope determines the boundaries of the project. It specifies what features and characteristics of the product and the functionalities that is included or not included in the project. In project management there are two types of scope – product scope and project scope. Product scope is what the project would create at the end. Project scope describes all the work involved in creating the product scope. It includes all the required work to complete the project deliverable (PMBOK®, Fifth Edition). Quality: Quality represents the extent in which the product is fit to meet customer’s expectations. It has agreed functionalities as per set standards, so that there is value for money for the customer. The purpose of project quality management is to ensure that the project will satisfy the needs for which it was undertaken. Quality, therefore, must be on equal footing with project scope, time and cost. If the stakeholders are not satisfied by the quality of the deliverables, the project can be termed as unsuccessful or failure (Tuman, 1986). Schedule: Schedule target is a limitation in a project that affects the start and end date of an activity. It takes form of fixed dates for activities. Projects have a variety of schedule constraints such as, imposed dates, key resource availability, logical task and activity duration limitation, etc. The goals of schedule targets include knowing status of the schedule, influencing the factors that cause schedule changes, determining that the schedule was changed, and managing changes when they occur (Lewin, 2001). Cost: Of all the above constraints cost keeps most businesses awake. The three challenges posed by cost constraints are lack of accountability, cost centers as commodities and unexpected budget cuts. To keep projects on track, project managers should also try to identify and eliminate non-critical physical resources before planning to retrench labor. Labor retrenchment or high attrition rates often leads to increased responsibilities or outsourcing jobs to independent contractors (Doloi, 2013). Motivation behind the study India provides a young IT-savvy English-speaking population, which is also cost effective. Other than the workforce, the environment for implementation of software projects both in the manufacturing sector as well as the services sector, appear very conducive in India. A comparative study on US, China and India on implementation of software projects, shows India on a high pedestal (Sykes, 2014). Over the past decade or more, India has emerged as a leader in IT offshore outsourcing world, by significantly expanding its offering across different verticals to enhance the depth of services. India’s advantage lies in its ability to provide a complete spectrum of services related to IT, in English-speaking countries, especially the US. Hence, the current study focuses on the Indian context of software project management. There are many studies conducted in the area of software project risk management with a perspective to implementable risk solutions. Yet software projects fail. This shows that there is a gap between the researchers and practitioners approach (Geethalakshmi & Shanmugam, 2008). Most of the research has been done in western countries. By contrast, the Indian scenario is largely different. This is because the Australasian Journal of Information Systems Volume 18 Number 3 2014 171 Indian market is not matured, approach to risk management is either non-existent or rudimentary and organization and HR perspective to risk management is highly unstructured (Geethalakshmi & Shanmugam, 2008). Taking these factors into consideration, there are not many studies conducted on software project risk in India. Thomas & Bhasi, (2011) reaffirm the above and state that there is scarcity of literature on software project risk management, especially from India. Research Objectives and Hypotheses The objective of the study is to determine the impact of diversified risk response strategies on achievement of project targets and overall project success. Risks can be either avoided, transferred, mitigated or accepted, each of which or a combination of which can have impact on the project outcomes. Hypotheses for the study are divided into two components. Hypotheses H11 to H14 are related to multiple regression models considering the achievement of project targets at an aggregative level. The next set of hypotheses i.e., H21 to H24 are associated with the equations of the SURE model. The overall structure of the hypotheses is presented in figure 2. The rightward portion of the figure describes individual multiple regressions, while the leftward portion captures the composite impact of the variables from the four risk response strategies on aggregate target achievement in the form of a set of simultaneous equations model. The hypotheses of the study can be summarized as under. Figure 2: Structure of the Hypotheses H11: Risk avoidance variables and factors enable meeting quadruple targets of scope & quality, schedule and costs targets; This hypothesis tests whether the factors associated with risk avoidance influence achievement of project targets. Accepting that risk response can range from avoidance to acceptance, Cook (2005) Australasian Journal of Information Systems Volume 18 Number 3 2014 172 argues that risk avoidance can be a serious affair, if the chances of risk mitigation are unacceptably low. Koller et al., (2012) discusses how risk-averse organizations can reduce risk by using effective risk avoidance strategies. H12: Risk transference variables and factors enable meeting project targets of scope & quality, schedule and costs; The project management team often finds it convenient to transfer risk from the core project team to the IT department, especially in the case of software projects, despite tight controls and professional approaches (Legault & Chasserio, 2012). Javed et al., (2013) discusses how project target achievement can be enhanced with appropriate risk transfer, after understanding users’ requirements through clear and concise output specifications, detailed study of the impact of the transfer and the costs and time associated with it. H13: Risk mitigation variables and factors enable meeting targets of scope & quality, schedule and costs targets; The next set of hypotheses discusses whether risk mitigation, as a risk response strategy influences meeting project targets. Verner et al., (2014) identified 85 risks and 77 risk mitigation strategies, categorizing them into four groups namely, outsourcing rationale, software development, human resources, and project management, the largest group of risks being related to project management. H14: Risk acceptance variables and factors enable meeting targets of scope & quality, schedule and costs targets. According to Drummond (2005), risk acceptance primarily consist of issues like, inaction against risk and its impact, evaluation of impact of risk occurrence, consciously accepting risk, evaluation of impact and time frame of risk, monitoring of change in the nature of risks across phases, and so on, that affect project outcomes. The hypotheses H21 to H24 captures a group of four equations considered simultaneously. However, the independent variables in each of these equations are filtered based on the rejection of the null hypotheses, which are selected based on the findings of the prior set of regressions. The dependent variable in these set of equations remain the same, i.e., achievement of overall project targets. The statements of alternative hypothesis for each of these equations are given below. H21: Selected avoidance variables influence achievement of overall project targets; H22: Selected transference variables influence achievement of overall project targets; H23: Selected mitigation variables influence achievement of overall project targets; H24: Selected acceptance variables influence achievement of overall project targets. It is expected that when the set of equations are considered in a composite manner the influence on the dependent variable may be captured differently. The output of the SURE model will throw further light on this aspect. Methodology The analytical framework of our study is based on estimating overall achievement of project success in terms of scope & quality, scheduling and cost targets – henceforth referred as PS_SQSC. The study is based on how various risk response strategies, namely avoidance (AVD), transference (TFR), mitigation (MTG) and acceptance (ACT) impact PS_SQSC. In other words, these four factors, i.e., AVD, TFR, MTG and ACT (referred to as ATMA, in short) form the independent variables in the study. These four factors constitutes of 15, 9, 14, and 8 items, respectively as described in Table 1. Australasian Journal of Information Systems Volume 18 Number 3 2014 173 The study is based on primary data, which was collected using a questionnaire. In the absence of any existing validated questionnaire that deals with risk response strategies in software projects, the researchers were required to develop a questionnaire. To design this questionnaire the study has extensively used the different facets of factors that influence the identification of risks in software projects and the risk response strategies as described by PMBOK®, (2013). The questionnaire also incorporated inputs from literature, extensively (Tesch et al., 2007, Carcary, 2013, Stoneburner et. al., 2002). Key informant technique was used to interview knowledgeable people in the industry and academia to understand whether such a study should be conducted. A long list of papers, as mentioned in literature was referred, to prepare an exhaustive list of variables and four categories, namely, avoidance, transference, mitigation and acceptance, was created. Tesch et al., (2007) have provided a detailed list of factors for two broad categories of risk response strategies, namely, avoidance and mitigation. Carcary (2013) has mentioned about the four risk handing strategies as considered for this study. The abovementioned paper builds more on Capacity Maturity Model perspective, rather than focusing on risk response strategies. Sillars & O’Connor (2009) discusses about alternative design solutions to reduce risks. The initial section of this questionnaire attempted to gather the personal profile of the respondents. Most of the questions were administered over a 5-point Likert scale, with 1 representing “strongly disagree” and 5 representing “strongly agree”. As coding of variables and questions is crucial in quantitative research, all questions were coded before administering the questionnaire, which was later decoded to covert in an excel worksheet for constructing quantitative models. Care was taken to ensure that the questionnaire does not consist of leading questions. In certain cases, when there was a scope of answering in a specific direction or pattern, the question was changed accordingly. In such cases, questions were based on operational aspects or project management, rather than asking what should be done. For example, in a Likert scale, two types of statements can be ranked. Statement – I: “The project manager attempted hiding project complexity from the customer.” Statement – II: “It is not necessary to disclose all the complexities associated with the project to the customer.” Statement – I is a leading question as compared to Statement – II, as the respondent would not easily agree that project complexity was hidden from the customer. This ensured proper diversity in responses across respondents. Risk avoidance, as a risk response strategy typically considers 15 variables that address issues like, adequate contingency plans, analysis of customers’ requirements, planning of project in phases, commitment made only after carefully studying team’s skillsets, monitoring of progress and change management, evaluation of business value of the project, pilot run of new technology, careful study of alternatives to new technology, etc. The next response strategy is risk transference. It consists of 9 variables and addresses questions like, whether the impact of risk transference was carefully studied, whether new risk was created after being transferred, whether mitigation was easier after risk transference, whether impact on overall risk was studied after transference decision was taken, whether risk transfer was a well thought after decision, whether cost and time of the risk transfer was low and whether transfer of risk increased project efficiency. Mitigation was the next risk response strategy consisted of 14 variables. The issues covered under mitigation generally included concerns like careful study of procedures, escalation of risk issues, when required, reconsideration of cost-benefit analysis, management’s perspective to risk, awareness of funding requirements, willingness of management to work closely with project team and provide adequate support, clear communication and information flow across stakeholders, keeping customers informed and updated at all phases of project and conducting periodic meetings, etc. Australasian Journal of Information Systems Volume 18 Number 3 2014 174 The last risk response strategy is risk acceptance comprising of 8 variables. Risk acceptance, as a risk response strategy primarily consist of issues like, not taking any action on risk and its impact, careful evaluation and acknowledgement of the probability of occurrence of risk, placing risk factors in watch list and studying their impact, conscious decision on accepting risk as it is, evaluation of impact and time frame of risk, monitoring of change in the nature of risks across phases, etc. Acronym Description Acronym Description Avoidance Variables Mitigation Variables AVD_CPM Communication between Project Head and Management MTG_PRI If required, stop project or escalate risk issues AVD_CSH Communication between Project Head and stakeholders MTG_CRS Lack of commitment on risk issues studied AVD_WL Project head identifies and resolves weak links MTG_MPS Management's perspective to risk studied AVD_PP Project planned in phases MTG_MCT Management's readiness to accept other communication tools AVD_PBT Project budgeted, one phase at a time MTG_CBC Re-evaluate cost-benefit calculations. AVD_ACP Adequate contingency plans are maintained MTG_FRP Awareness on funding requirements, at each phase AVD_PFS Project feasibility study was conducted MTG_CRP Communicate risk assessment results periodically AVD_BVE Business value of the project was evaluated MTG_SFD Keeping stakeholders informed about funding deficits AVD_PNT Pilot run of new technology MTG_MDM Management aware of deliverables & means to meet AVD_CRA Risks to meeting customers’ requirements analyzed MTG_WMW Willingness of management to work with project team AVD_ANT Alternatives to new technology MTG_PSF Processes strictly followed AVD_RRM Roles and responsibility matrix MTG_AGC Updating customers through regular meeting AVD_CSS Commitment was made after studying skills MTG_ACC Project achievement gap communicated to customer AVD_CMM Progress and change management was monitored MTG_DCM All changes discussed with customer and management AVD_UPF End user participated in feedback Australasian Journal of Information Systems Volume 18 Number 3 2014 175 Transference Variables Acceptance Variables TRF_DSR Possibility of detecting source of risk ACT_REA Risk factors evaluated and acknowledged TFR_PRS Presence of risk for each phase studied ACT_RWS Risk factors were in watch-list and & studied TFR_ORS Impact of shifting risk to another phase studied ACT_RTD No action of risk was taken as a decision TFR_RTS Impact on overall risk after shifting, studied ACT_REP Probability of occurrence of risk evaluated periodically TFR_RTM When risk transferred, it is easily mitigated ACT_RFE Impact and time frame of risk factors evaluated TFR_TNR Transfer of risk does not create new risk ACT_RSA Each risk factor studied for immediate action TFR_TRL Cost and time to transfer risk is low ACT_CRM Change in nature of risk across phases, monitored TFR_RIE Transfer of risk increases efficiency ACT_TRI Taking no action on risk & its impact TFR_RTD Risk transfer was well-thought decision Table 1: The list of variables constituting ATMA factors are as listed below: Questionnaire Design and Sample Selection To identify the sample for the above administered questionnaire, a "Population Frame" was first defined. The population frame helped us addressing a select group of respondents, yet maintaining the randomness and representativeness of the population. In order to do so, it was a desirable trait that the project managers who were interviewed had some knowledge about risk management, and the methodologies, techniques and tools in this area. Also, companies that they work for should be undertaking projects regularly, conforming to definition of project, as per the PMBOK® Guide. Keeping this in mind, the following criteria were identified to determine the population frame. Before selecting the sample, it was checked whether the respondent had at least minimum of 5 years of work experience and had attended a training program in project management. The whole focus of data collection was concentrated on IT and ITES companies. No response was taken from any individual, unless the project size she dealt with was more than INR 10 million or more. There was no rationale in deciding this cut-off – the purpose was to make sure responses from very small projects are avoided. From PMI India chapters Training Centers (Registered Education Providers) were identified. From this exhaustive list of 70 training centers a database of companies which provided project management training was identified. Out of the 70 training centers, 31 centers shared this data, under strict confidentiality clause, where it was agreed upon that the data will be used solely for academic purpose, without disclosing names of companies or respondents. In some cases, individuals were directly contacted for response, while in others, the Training & Development department or the HR departments were contacted to identify employees who could be potential respondents. In this way, the online questionnaire was circulated using Survey Monkey, a commonly used online survey portal, to 3448 persons. Out of these, responses were received from 1206 respondents. Out of these 1206 respondents, there were 612 responses which were incomplete, despite repeated follow-ups. From the rest 594 responses, 292 responses were invalid. In these 292 cases, it was observed that the respondents, may be due to certain pressure from seniors, had filled in the responses, but there was no variability across answers, or the cross-check questions proved that they did not respond seriously. For example, for Australasian Journal of Information Systems Volume 18 Number 3 2014 176 several respondents it was observed that all the responses had a single answer “5”. Hence, after removing all such irrelevant data, the researchers were left with 302 responses. Later, coding / decoding was performed on the raw data from 302 respondents for further statistical analysis. Once the questionnaire was designed based on the literature, key informant technique was used for taking inputs from five reviewers who serve as project management trainers in the corporate sector. Before administering the questionnaire, a pilot survey was conducted amongst 7 PMI Trainers and12 Project Leads. Critical comments from these 19 responses were incorporated in the questionnaire. This process was very useful and strengthened the questionnaire. Data was collected using an online tool called SurveyMonkey, that automatically helps collaging the data in excel worksheets. The format of the questionnaire in Survey Monkey required coding for several questions. Hence, after collection of raw data, the excel worksheets were processed by decoding the data and converting it to usable format. Analytical Framework To test for internal consistency of these items, derived from Likert scale, Cronbach’s Alpha was used to test for reliability of data. The cut-off for Cronbach’s Alpha was 0.70. After the reliability test the number of items for the variables AVD, TFR, MTG and ACT and reduced to 14, 8, 14 and 8 items, respectively. The summary results of Cronbach’s Alpha is given in table 2. Variable categories Initial Cronbach's Alpha Original number of Items Revised Cronbach's Alpha Revised number of Items List of Items Deleted Avoidance (AVD) 0.6865 15 0.7232 14 Alternatives to new technology (AVD_ANT) Transference (TFR) 0.6846 9 0.7989 8 Possibility of detecting source of risk (TRF_DSR) Mitigation(MTG) 0.8473 14 - - - Acceptance (ACT) 0.7471 8 - - - Table 2: Reliability Test: Summary Results from Cronbach's Alpha Quantitative models were performed in two stages – in the first stage four multiple regressions were conducted considering PS_SQSC as the dependent variable in each case and the variables under the ATMA factors as the independent variables. Multiple regressions were performed using EViews 8.0. All the regression outputs are White’s Heteroscedasticity consistent. The Regression outputs have also been substantiated with Multicollinearity tests using Tolerance. Tolerance captures the extent of variability in an independent variable not captured by other independent variables. Hence, the higher the value, the more unique is the variable. Generally, a tolerance value higher than 0.30 is considered as good and ensures relief from multicollinearity problem. Findings from regression models The first regression was performed considering 14 independent variables under avoidance with PS_SQSC as the dependent variable. It was observed that the overall explanatory power (R-Squared = 0.30) of the independent variables is not very impressive with only one variable – AVD_PNT emerging Australasian Journal of Information Systems Volume 18 Number 3 2014 177 significant at 99 percent level of confidence. The variable represents the extent to which pilot run on new technology was performed, before implementing on the project. A high score would imply that effective pilot runs on new technology would largely avoid recurrence of project risk. If pilot runs are conducted on new technologies, it can help complete projects on time, thereby shortening the project cycle (Li, 2009). Two variables namely, AVD_BVE and AVD_RRM emerged significant at 95 percent level of confidence. The variables represent adequate evaluation of business value of a project and the correct use of “Roles and Responsibility” matrix to identify problem areas. Both the variables being directly proportional to PS_SQSC, it would imply that higher values of AVD_BVE and AVD_RRM will lead to higher efficiency in avoiding risk. Quartel et al., (2012) asserts that an architecture-based approach to IT software project evaluation can assess the business value of a project better and helps in meeting project targets. Again projects can be highly successful if there is clarity over roles and responsibilities of project team members (Evans et al., 1983). The other two variables which were mildly significant at 90 percent level of confidence are AVD_CPM and AVD_PP. While AVD_CPM implies free flow of communication between the project head and the management, AVD_PP implies proper phased planning of project. Both the variables are directly proportional to overall achievement of targets. Massey & Kyriazis (2007) discusses the importance of smooth and transparent communication between project head and management. Tasevska et al., (2014) highlights the significance of phased planning of project and its positive implications on project success. The second multiple regression was performed considering the transference variables, again, PS_SQSC being the dependent variable. The overall explanatory power of this model is similar to Avoidance (R- Squared = 0.29). In this model, TFR_PRS was significant at 99 percent level of confidence. In lines with the study of Korrapati & Kocherla (2010), it appears that if the presence of risk is carefully studied to understand and appreciate the nature of risks, transference of risk would not be a threat to success. The other two variables, namely TFR_RTD and TFR_TRL are significant at 95 percent level of confidence. This would imply that if cost and time involved in transference of risk is low and the transfer was a well-thought-after decision, project success can be achieved in terms of PS_SQSC. Armstrong & Paolucci (2010) observe that a systematic planned transfer of risk within departments of project can enable achievement of project targets. Mouraviev & Kakabadse (2014) argue that a project is benefited if risk transference is prompt and cost effective. Australasian Journal of Information Systems Volume 18 Number 3 2014 178 Dependent Variable: PS_SQSC Method: Least Squares Sample: 1 302 White heteroskedasticity-consistent standard errors & covariance [Risk Response Strategy: Acceptance] [Risk Response Strategy: Transference] Variable Coeff. Prob. Tolerance Variable Coeff. Prob. Tolerance C 1.1740 0.0000 C 1.0233 0.0000 ACT_CRM 0.0655 0.1148 0.6588 TFR_ORS 0.0808 0.1257 0.5818 ACT_REA 0.0484 0.3668 0.6332 TFR_PRS 0.2145 0.0000 0.7417 ACT_REP 0.0212 0.6968 0.7296 TFR_RIE 0.0449 0.4206 0.5566 ACT_RFE 0.0864 0.0542 0.7834 TFR_RTD 0.1135 0.0323 0.6126 ACT_RSA 0.1859 0.0001 0.6586 TFR_RTM -0.0655 0.2435 0.5983 ACT_RTD -0.0531 0.3494 0.5477 TFR_RTS 0.0260 0.6040 0.5053 ACT_RWS 0.0606 0.2445 0.5283 TFR_TNR 0.0761 0.1413 0.6755 ACT_TRI 0.1902 0.0000 0.8000 TFR_TRL 0.1277 0.0162 0.6897 R-squared 0.3267 R-squared 0.2903 Adjusted R-squared 0.3084 Adjusted R-squared 0.2684 F-statistic 17.7746 F-statistic 13.2286 [Risk Response Strategy: Avoidance] [Risk Response Strategy: Mitigation] Variable Coeff. Prob. Tolerance Variable Coeff. Prob. Tolerance C 0.7301 0.0017 C 0.2229 0.1866 AVD_ACP -0.0773 0.2134 0.6308 MTG_ACC 0.0558 0.0993 0.5557 AVD_BVE 0.1052 0.0324 0.6351 MTG_AGC 0.0596 0.0741 0.5906 AVD_CMM 0.0552 0.4042 0.6251 MTG_CBC 0.0254 0.3726 0.7442 AVD_CPM 0.0839 0.0862 0.5579 MTG_CRP 0.1542 0.0000 0.5973 AVD_CRA 0.0157 0.7558 0.6895 MTG_CRS 0.0052 0.8421 0.9059 AVD_CSH 0.0213 0.6283 0.7962 MTG_DCM 0.1200 0.0004 0.5577 AVD_CSS 0.0381 0.5048 0.6184 MTG_FRP 0.0392 0.3359 0.6123 AVD_PBT -0.0146 0.7763 0.7568 MTG_MCT 0.0923 0.0039 0.6397 AVD_PFS 0.0560 0.1257 0.7245 MTG_MDM 0.1493 0.0001 0.5847 AVD_PNT 0.2263 0.0003 0.6240 MTG_MPS 0.0692 0.0253 0.7319 AVD_PP 0.0770 0.0914 0.5622 MTG_PRI 0.0378 0.1511 0.6916 AVD_RRM 0.0860 0.0475 0.5827 MTG_PSF 0.2150 0.0000 0.7159 AVD_UPF 0.0219 0.6537 0.6967 MTG_SFD -0.0306 0.3806 0.5528 AVD_WL 0.0182 0.6668 0.5741 MTG_WMW -0.0324 0.3286 0.5030 R-squared 0.3019 R-squared 0.6799 Adjusted R-squared 0.2653 Adjusted R-squared 0.6643 F-statistic 8.2442 F-statistic 43.5432 Table 3: Multiple Regression of ATMA The third multiple regression considered mitigation variables with PS_SQSC as the dependent variable, as before. This is the regression that reaped the highest explanatory power with 0.6799 R-Squared. This implies that mitigation is the most frequently used risk response strategy for project managers in the software industry. Out of 14 variables, five variables, namely, MTG_CRP, MTG_DCM, MTG_MCT, MTG_MDM and MTG_PSF emerged significant at 99 percent level of confidence. There was one Australasian Journal of Information Systems Volume 18 Number 3 2014 179 variable significant at 95 percent level (MTG_MPS) and two variables significant at 90 percent level of confidence (MTG_ACC, MTG_AGC). Risk mitigation being an aggressive stance to risk management, organizational consent is important. To gain organization’s confidence and convince the top management to mitigate risk, periodic communication even before the commencement of the project, is essential. Following this, periodic communication of project progress, and other risk assessment measures and their impact has to be shared with the top management. Goble & Bier (2013) opines that having a clear communication channel can itself be termed as a risk mitigation strategy. If there are changes in customers’ expectations or changes in the scope of the project, it is important to discuss the possibility of incorporating such changes in the project clearly between the clients, project managers and top management (Holzmann & Panizel, 2013). Management’s perspective to risk and their readiness to accept other forms of communication makes meetings project targets easier. A strong internal communication and keen interest would also ensure management to be completely aware of the project deliverables and the means to attain them (Aubry, 2011). Implementation of strict processes and detailed documentation along with commitment and support of top management would also help attainment of project targets Bolles et al., (2006). From the perspective of the project team, it is required to be aware of management’s perspective to risk handling (Tesch et al., 2007). Moreover, if risk assessment results are communicated periodically to all stakeholders and all changes associated with project communicated to customers and management, thereby making customer aware of achievement gaps, project success can be largely attained in terms of scope & quality, scheduling and cost. The fourth and the last regression was conducted using 8 Acceptance variables. The overall R-Squared for this regression is 0.3267, which is approximately similar to avoidance and transference, though slightly higher than the two. Three variables namely, ACT_RSA, ACT_TRI and ACT_RFE emerged as significant – the first two variables are significant at 99 percent level and the third at 90 percent level of confidence. This largely implies that careful study of risk factors, postponement of immediate action on current risk and its impact, and evaluation of impact and duration of risk factors are the principal ways in which acceptance strategies are taken up to respond to risk. Olawale & Sun (2010) identify a list of similar factors for risk acceptance and immediate action. Hence, in a nutshell, the output of the four multiple regression models indicate that project managers are more inclined to consider mitigation as a risk response strategy. Having said that, acceptance, transference and avoidance also provide interesting dimensions to risk response strategies, in the current study. If the impact of risk is carefully studied, accepting or transferring risks has emerged as a viable option which is predominantly applied by project managers to achieve project targets. Along with transparency in the flow of communication, advanced planning of projects in a phase-wise manner and correct evaluation of the business value of a project, avoidance can also be considered an effective strategy in providing risk solutions. Findings from SURE model As there are four different risk response strategies impacting the same dependent variable PS_SQSC, an alternative model was tried that can consider all the four equations as a system and evaluate the impact on PS_SQSC, jointly. When the problem is to estimate project success from more than one equation, the disturbances in these different equations at a given point of time are likely to reflect some common immeasurable or omitted factors, and hence could be correlated. For example, in the present study of estimating PS_SQSC, the effect of Avoidance, treated as a set of independent variables, under the four risk response strategies, mentioned above, is likely to have related effects on the disturbances of the four equations. Correlation between disturbances from different equations at a given point of time is known as contemporaneous correlation. Australasian Journal of Information Systems Volume 18 Number 3 2014 180 When contemporaneous correlation exists, it may be more efficient to estimate all equations jointly, rather than to estimate each one separately using least squares. Separate estimation of each of the relations ignores the possible relatedness of the equation errors. The appropriate joint estimation technique is often known as Seemingly Unrelated Regression Estimation (SURE) (Zellner, 1962). Although the technique is described in the context of estimating a number of equations using time- series data, they can be equally relevant for cross-sectional data. If cross-sectional data were used to estimate different types of project success functions, then it is quite likely that some immeasurable characteristics of a given project could have similar effects on the disturbances of all the project success functions. The distinguishing feature of seemingly unrelated regressions as a method of pooling time- series and cross-sectional data, is contemporaneous correlation in the disturbances and the assumption that each cross-sectional unit has a different coefficient vector. Under the SURE method we want to take into account of the fact that the errors for the simultaneous equations may be contemporaneously (same time period) correlated and thus the off-diagonal blocks in the above equation may not be equal to zero. The system of Seemingly Unrelated Regression Equations (SURE) provides the researchers with the scope of taking the contemporaneous correlation into account and the conditions under which it is possible to improve on separate least squares estimation of a number of equations. If we have m seemingly unrelated regression equations, the complete model may be written as miuXy iiii ,,2,1 , (1) The complete set of equations is given as: mmmm UXy UXy UXy ............ 2222 1111 (2) where yi and ui (i=1, 2, …, m) are of dimensions (n 1), Xi is (n ki), and i is (ki 1). We should note that each equation need not have to have the same number of explanatory variables. In matrix form we write m 2 1 m 2 1 m 2 1 m 2 1 u u u X000 000 00X0 000X y y y (3) or as Y=X U (4) Australasian Journal of Information Systems Volume 18 Number 3 2014 181 where Y, X, and U are matrices of dimensions respectively, (mn 1), (mn × k), (k × 1) and (mn 1) with . 1 m i ikk Since, the design matrix X is of the block-diagonal form, the application of OLS to equation (4) treated as a simple regression, would be exactly equivalent to the application of OLS to each equation of the m equations in equation (2) separately. It is useful to test the presence of heteroscedasticity and contemporaneous correlation embodied in the systems equations. Primary study of residual plots generated by EViews 8.0 verifies the presence of contemporaneous correlation. There are four equations determining project success in terms of scope & quality, scheduling and cost (PS_SQSC). There are intercept terms with all the equations ( 10, 20, 30, 40 and 50), which implies that if the other factors influencing project success are absent, there is an autonomous component responsible for it. The exogenous variables are quantitative. On an a priori basis, we assume that, the coefficients of the exogenous variables are not equal to zero, i.e. ij, ij 0. ‘i’ denotes the source from which project success is measured, based on which the equation is framed and ‘j’ denotes the exogenous variable. That is, each project success equation denotes the project success for the ith source from the jth respondent. In the present set of equations i = 1, 2, 3 and 4 – all representing PS_SQCS as the dependent variable. The independent variables are the same as considered for the four independent multiple regression models conducted earlier. It is also to be notes at this point that all the variables which were considered under the ATMA are not considered for the SURE model. For the SURE model we have considered only those variables from ATMA, which were significant at 99, 95 and 90 percent level of confidence. Other variables were dropped out from the SURE model. Hence, the system of equations for the SURE model is as follows: CPMAVDBVEAVD PPAVDRRMAVDPNTAVDSQSCPS __ ____ 1514 13121110 RTDTFRTRLTFRPRSTFRSQSCPS ____ 23222120 AGCMTGMPSMTGACCMTGMCTMTG DCMTFRMDMMTGPSFMTGCRPMTGSQSCPS ____ _____ 38373635 3433323130 RFEACTTRIACTRSAACTSQSCPS ____ 43424140 The output of the SURE model is different and also interesting, as compared to the individual multiple regressions performed earlier. Let us at first discuss the explanatory power of the four equations as generated by EViews 8.0. In sharp contrast to the earlier results, here it is found that avoidance and transference variables have very little impact on PS_SQSC, both registering an R-Squared of 0.07. Acceptance, represented by the last equation in the SURE model, has showed an R-Squared of 0.12, which is higher than avoidance and transference. As expected, mitigation has generated an R-Squared of 0.56, which is substantially higher than all the other three factors of risk response strategies. This clearly indicates that project managers do not consider the other mechanisms to respond to risk more conspicuous compared to mitigation. Acceptance, as a risk response strategy is the next most influential, after mitigation. Australasian Journal of Information Systems Volume 18 Number 3 2014 182 System: UNTITLED Estimation Method: Seemingly Unrelated Regression Date: 12/04/13 Time: 13:55 Sample: 1 302 Included observations: 302 Total system (balanced) observations 1208 Linear estimation after one-step weighting matrix Coefficient Std. Error t-Statistic Prob. 10 2.7231 0.099969 27.23953 0.0000 11 0.036464 0.02522 1.445834 0.1485 12 0.017626 0.019776 0.891291 0.3730 13 0.010502 0.021254 0.494144 0.6213 14 0.011315 0.024931 0.453838 0.6500 15 0.008897 0.022177 0.401208 0.6883 20 2.736259 0.094499 28.95543 0.0000 21 0.037303 0.019766 1.88723 0.0594 22 0.017697 0.021486 0.823669 0.4103 23 0.026438 0.021474 1.231141 0.2185 30 1.348957 0.094228 14.31595 0.0000 31 0.08806 0.023816 3.697474 0.0002 32 0.128626 0.023889 5.384337 0.0000 33 0.083709 0.023167 3.613223 0.0003 34 0.068328 0.024644 2.772575 0.0056 35 0.057879 0.022048 2.625182 0.0088 36 0.047473 0.022874 2.075382 0.0382 37 0.049858 0.021289 2.341888 0.0194 38 0.041301 0.025334 1.630249 0.1033 40 2.643774 0.097333 27.16226 0.0000 41 0.047718 0.026421 1.806063 0.0712 42 0.048899 0.021759 2.247259 0.0248 43 0.017278 0.024248 0.71256 0.4763 Table 4: SURE Model The output under the SURE model did not witness all independent variables to emerge as significant. In fact, other than variables pertaining to Mitigation, no other risk response strategy emerged to be significant at 99 percent level of confidence. The variables that emerged significant at 99 percent level of confidence are MTG_CRP, MTG_PSF, MTG_MDM, MTG_DCM and MTG_MCT. The other variables which were significant at 95 percent level of confidence are MTG_ACC, MTG_MPS. Two variables were significant as far as Acceptance is concerned – one at 95 percent level of confidence Australasian Journal of Information Systems Volume 18 Number 3 2014 183 (ACT_TRI) and the other ACT_RSA, significant at 90 percent level of confidence. The only variable which was significant at 90 percent level of confidence in Transference is TFR_PRS. Unfortunately, there was no variable that emerged to be significant from avoidance. The results of the SURE model are indeed interesting, as the independent variables used in the set of equations are a selected few, which emerged significant in the multiple regressions. Just like the results of the multiple regressions, mitigation has again displayed the highest influence on achievement of project targets. According to the study, risk mitigation mostly revolves around effective communication across all parties involved in the project. The findings reveal that periodic communication of risk assessment results including discussions on change of project scope with customers and management, keeping management and other stakeholders aware of project deliverables and means to meet and strict adherence to procedures which have been set by top management in concurrence with project manager and team members, management’s readiness to accept different forms of communication tools, transparency in continuous gap analysis of target achievements with customers and top management and study of management’s perspective to risk are the significant determinants of risk mitigation. It was also found that risk can be transferred to another phase of the project, after careful study of its nature in the current phase. Hence, if transference of risk has the likelihood of increasing its impact after transference, it should be avoided. Korrapati & Kocherla (2010) suggest that ex post phase-wise analysis of risks over several projects can provide such crucial knowledge on whether transference would be the best strategy. Acceptance of risk in the form of not taking any action, after thorough study of the potential threat of each and every risk factor, has emerged as an effective risk response strategy (Berkeley, et al., 1991). Often, in the Indian context, despite various sophisticated studies in risk management, practical and easily adoptable risk framework is largely missing (Dey, 2012). Hence, taking no action on risk and its impact is often a strategy that project managers would adopt. This variable has emerged significant in the current study. DISCUSSION The study demonstrates that Indian companies prefer mitigation as the most prominent response strategy to achieve the quadruple targets of scope & quality, schedule and cost. Though major international studies reiterate about all four responses strategies applied in project risk management at different levels, in India the major response strategy as perceived by project managers is Mitigation. The findings of the present study offer a lot of insights on the practices being followed in the implementation of risk management. The study reveals that project stakeholders who perceived that organizations that follow processes strictly, as laid down by the management tended to misreport less. As observed by Smith et al., (2006) the existence of team spirit and a caring environment did not necessarily imply a robust reporting structure (Smith et al., 2006). In other words, a process-oriented approach to risk management reaps better benefits than loosely bound processes, which are not well-defined. Assessing risk management periodically and communicating it to the management and customers, can help resolve major uncertainties and lead to project success. Using a phase-wise approach towards risk assessment and management can occur with effective interaction and cooperation between project managers and other stakeholders involved in the process. Methods to explore and develop free flow of communication within the organization and between the stakeholders can help managing risk more effectively (Thompson & Bloom, 2000). At different phases of the project, top management, project steering committee, and internal & external stakeholders should be aware of the deliverables. The steering committee plays a critical role together with the sponsor in approving the project scope, Australasian Journal of Information Systems Volume 18 Number 3 2014 184 deliverables and financials. Their responsibilities with respect to project management are to provide support to the project team to ensure a smooth project delivery process and implementation. The specific response strategies under the overall ATMA factors, mentioned above play a fundamental role to impact the quadruple targets of scope & quality, schedule and cost. Processes, which are mostly tailor-made to meet the objectives and requirements of the projects, are targeted to meet the deadlines, maintain quality, avoid rework and conflict and improve productivity, in a realistic manner. For example, if a software product is to be deployed in a client location, there is a possibility that testing the smooth installation is accidentally left out, due to the lack of existence of a properly defined check- list. This can, in turn, delay the process of activation of the software and lead to several other problems in project implementation. Communicating risks in projects requires special skills, project managers often share information about project risks ineffectually or not at all, and hence projects suffer unnecessary set back. Communicating risks at a scheduled time regularly scheduled team meetings, in scheduled progress reports and upper- management reviews, and in special meetings will increase the likelihood of controlling projects from any kind of risks that might increase. In a nutshell, the findings suggest that risk management is an integral part of project management and it needs to be weaved with all the process groups of initiating, planning, executing, monitoring and controlling, and closing. Risk can be effectively controlled through proper communication using different modes, for example, formal or informal, spoken or written, manual or electronic, amongst various stakeholders, as applicable to each milestone to achieve the targets of scope & quality, schedule and cost (PMBOK®). CONCLUSIONS The objective of the study was to investigate the risk response strategies that influence the achievement of scope & quality, schedule and cost targets in software firms in India. Based on the literature, key informant technique and pilot survey, a questionnaire was designed to collect primary data from 302 respondents. Variables under four broad categories namely, avoidance, transference, mitigation and acceptance (ATMA) were considered to form the list of independent variables. Applying Cronbach’s Alpha, two variables were removed as a part of reliability check. We have used two forms of quantitative models in this study. Four multiple regressions were conducted using project success to achieve the quadruple targets (PS_SQSC), as the dependent variable and the variables under each of the risk response strategies (ATMA) as the independent variables in the different regression models. Separately, a set of Seemingly Unrelated Regression Equations (SURE) model was also used as a part of the analysis where the dependent variable was the same but the independent variables includes only those which emerged significant in the prior multiple regression models. This helped the study to get a holistic picture of the risk response strategies’ impact on meeting project targets. Irrespective of the category of risk response strategy, clear, transparent and free flow of information and communication have emerged as key solutions to risk. Apart from that, in-depth knowledge of all stakeholders on the changing nature of risks in software projects is of paramount importance. Mitigation of risk emerged as the most significant factor in both the models used in the study. The other three factors namely, avoidance, transference and acceptance have nearly the same influence on PS_SQSC. In the development phase of a project, mitigation of risks plays an important role. Sakthidaran (2010) includes user involvement, requirements, user and management support, managing innovation, complexity, scope of work, project management practices, and training as important variables that influence project success. The common thread that bonds all these variables in risk mitigation is the effective flow of communication across levels. Poor communication practices often lead to unclear project objectives and improper project control (Kerzner, 2013). Australasian Journal of Information Systems Volume 18 Number 3 2014 185 The future scope of research in the topic would include a couple of options. A cross-border analysis of the ATMA model and its influence on achieving project targets would be an interesting study. It will be interesting to note whether mitigation emerges as the most significant risk response strategy in other emerging economies. As this study is limited to software industry, there is a scope of expanding it to other industries to produce a comparative analysis of risk response strategies. The study also considers risk management from the software development life cycle perspective. However, the approach to risk management in software projects can also be undertaken for agile processes like SCRUM, EXTREME programming and Crystal methodologies. While the paper largely assumes that project managers have the authority of employing risk solutions, the reality to be far from this. There can be either a steering committee or even active involvement of top management and their perspective to risk that can determine the implementation of risk response strategies. Also, as discussed earlier, approach to risk has two perspectives (Gasparini et al., 2004) – the static model and the dynamic model. There is a future scope of research to apply sophisticated statistical models in the area of dynamic risk management, where learning from each sage of the project and previous projects can be incorporated on an iterative basis to manage project risks better. As software or IT projects have low gestation periods, a static model to risk management is largely acceptable and the projects’ scope & quality requirements do not change much. For large projects in the area of manufacturing, especially, infrastructure, dynamic risk management models would be more effective, as the requirements for the projects and the identified risks can change. The authors conclude that planning of risk is vital to every project success but implementing it with the appropriate risk response strategy is a must. Apart from planning, transparency of communication within project stakeholders is imperative. Software industry is ever-evolving and currency is crucial to the industry, which differentiates it from other industries. This factor of continuous evolution of the industry makes it more vulnerable to risks. Hence, a major key to software project success is impromptu application of risk response strategies. REFERENCES Abd, K.; Abhary, K.; Marian, R.; (2014); Simulation modeling and the analysis of scheduling in robotic flexible assembly clls using Taguchi method; International Journal of Production Research; 52 (9), 2654-2666. Abdul-Rahman, H., Mohd-Rahim, F. a. and Chen, W. (2012) Reducing failures in software development projects: effectiveness of risk mitigation strategies. Journal of Risk Research, 15, 417-433. Agarwal, N., & Rathod, U.; (2006). Defining ‘success’ for software projects: An exploratory revelation. International Journal of Project Management, 24(4), 358-370. Alexandra-Mihaela, P., & Danut, D. D. (2013); The measurement and evaluation of the internal communication process in project management; Annals of the University of Oradea, Economic Science Series, 22(1). Augustine S., Bob P., Fred S., and Susan W. (2005). Agile project management: Steering from the edges. Communications of the ACM, 48(12), 85-89. Alkass, S.; Al-Jibouri, S.; Techakosol, V.; (2006); Feasibility studies: A case for using a stochastic approach; AACE International Transactions; 6.1-6. Alter, S., Ginzberg, M., (1978), Managing Uncertainty in MIS Implementation, Sloan Management Review, 23 – 31. Australasian Journal of Information Systems Volume 18 Number 3 2014 186 Armour, P. G. (2005). Project portfolios: organizational management of risk. Communications of the ACM, 48, 17-20. Armstrong, J.; Paolucci, F.; (2010); Risk equalization in Ireland and Australia: A simulation analysis to compare outcomes; Geneva Papers on Risk & Insurance - Issues & Practice; 35 (4), 521-538. Aubry, M.; (2011); The social reality of organizational project management at the interface between networks and hierarchy; International Journal of Managing Projects in Business; 4 (3), 436- 457. Bagdonien , D.; Simanavi ien , A.; (2012); Effective project team training; Economics & Management. 17 (3), 1165-1170. Berkel, R.; (2014); Quasi-markets and the delivery of activation – A frontline perspective; Social Policy & Administration; 48 (2), 188-203. Berkeley, D.; Humphreys, P. C.; Thomas, R. D.; (1991); Project risk action management; Construction Management & Economics; 9 (1), 3. Blackstone, J. H.; Cox, J. F.; Schleier, J.G.; (2009); A tutorial on project management from a theory of constraints perspective; International Journal of Production Research; 47 (24), 7029-7046. Boehm, B. W. (1989). Software risk management tutorial, IEEE Computer Society Press, Los Alamitos, California. Boehm, B. W. (1991). Software risk management: principles and practices. Software, IEEE, 8, 32-41. Bolles, Dennis L.; Hubbard, D. G. (2006), Integrating projects with business strategies and objectives: 4.5 key points for project business management planning success; Power of Enterprise-Wide Project Management. p41-42. Burström, T.; Jacobsson, M.; (2011); The role and importance of ‘glue people’ in projects; IUP Journal of Soft Skills; 5 (1), p7-15. Byoun, S.; Kim, J.; Yoo, S. S.; (2013); Risk management with leverage: evidence from project finance; Journal of Financial & Quantitative Analysis;48 (2), 549-577. Cardenas, J. A.; Gemoets, L.; Ablanedo R., Jose H.; Sarfi, R.; (2014); A literature survey on smart grid distribution: an analytical approach; Journal of Cleaner Production; 65, p202-216. Carcary, M. (2013). IT Risk Management: A Capability Maturity Model Perspective. Electronic Journal of Information Systems Evaluation, 16(1). Cavusgil, S. T.; Sikora, E.; (1988); How multinationals can counter gray market imports; Columbia Journal of World Business; 23 (4), 75-85. Chan, E. H.W.; Au, M. C.Y. (2007); Building contractors’ behavioral pattern in pricing weather risks; International Journal of Project Management; 25 (6), 615-626. Chandra, A., & Calderon, T. G. (2009). Information intensity, control deficiency risk, and materiality. Managerial Auditing Journal, 24(3), 220-232. Cook, P.; (2005); Formalized risk management: Vital tools for project and business success; Cost Engineering; 47 (8), p12-13. Davis, G. B.; (1982); Strategies for information requirements determination; IBM Systems Journal; 21(1), 4-30. Dey, P. K.; (2012); Project risk management using multiple criterion decision-making technique and decision tree analysis: a case study of Indian oil refinery; Production Planning & Control; 23 (12), 903-921. Doherty, N. F., King, M., & Al-Mushayt, O., (2003), The impact of inadequacies in the treatment of organizational issues on information systems development projects, Information & Management. 41, 49-63. Australasian Journal of Information Systems Volume 18 Number 3 2014 187 Doloi, H.; (2013); Cost overruns and failure in project management: understanding the role of key stakeholders in construction projects; Journal of Construction Engineering & Management; 139 (3), 267-279. Drummond, H.(2005); What we never have, we never miss? A study of entrapment in a small business; Journal of Information Technology; 20 (3), 170-176. Dvir, D. and Shenhar, A. J., (1992) Measuring the Success of Technology based Strategic Business Units, Engineering Management Journal, 4, 33-38. Eicher, J.; Ruder, D.; (2007); Business process analytics: A new approach to risk; Journal of Alternative Investments; 10 (2), 76-84. Evans, M. W., Piazza, P., Dolkas, B., (1983). Principles of Productive Software, John Wiley and Sons, Inc. New York, NY, USA. Fairley, M. E.; (2005); Software risk management; IEEE Software;. 22 (3), 101-101. Ferreira, S., Collofello, J., Shunk, D., & Mackulak, G. (2009); Understanding the effects of requirements volatility in software engineering by using analytical modelling and software process simulation. Journal of Systems and Software, 82, 1568-1577. Gasparini, M., Margaria, G., & Wynn, H. P. (2004). Dynamic risk control for project development. Statistical Methods and Applications, 13(1), 73-88. Golden, L. L.; Wang, M.; Yang, C.; (2007); Handling weather related risks through the financial markets: consideration of credit risk, basic risk and hedging; Journal of Risk & Insurance; 74 (2), 319-346. Goble, R.; Bier, V. M.; (2013); Risk assessment can be a game-changing information technology – but too often it isn’t; Risk Analysis: An International Journal; 33 (11), 1942-1951. Hanisch, B.; Wald, A.; (2012); A bibliometric view on the use of contingency theory in project management research; Project Management Journal; 43(3), 4-23. Hecker, J. Z.; (2002); Hazard mitigation: Proposed changes to FEMA’s multihazard mitigation programs present challenges; GAO Reports. 46. Hillson, D. (2002). Extending the risk process to manage opportunities. International Journal of project management, 20(3), 235-240. Holzmann, V.; Panizel, I.; (2013); Communications management in Scrum projects; Proceedings of the European Conference on Information Management & Evaluation; 67-74. Fisher, K. T.; Urich, P. B.; (1999), Information dissemination and communication in stakeholder participation: the Bohol Cebu water supply project; Asia Pacific Viewpoint; 40(3), 251. Geethalakshmi. S.N., and Shanmugam. A., (2008); Success and Failure of Software Development: Practitioners’ Perspective; Proceedings of the International MultiConference of Engineers and Computer Scientists; 1, Hong Kong. Goble, R.; Bier, V. M.; (2013); Risk assessment can be a game-changing information technology – but too often it isn’t; Risk Analysis: An International Journal; 33 (11), 1942-1951. Javed, A. A.; Lam, P.T.I.; Zou, P. X.W; (2013); Output-based specifications for PPP projects: Lessons for facilities management from Australia; Journal of Facilities Management; 11(1), p5-30. Johnstone, K.M.; (2000); Client-Acceptance decisions: Simultaneous effects of client business risk, audit risk, auditor business risk, and risk adaptation; Auditing; 19 (1), 1-25. Karolak, D. W.; (1996); Software engineering risk management; Los Alamitos, CA; IEEE Computer Society Press. Australasian Journal of Information Systems Volume 18 Number 3 2014 188 Khamooshi, H.; Cioffi, D. F.; (2013); Uncertainty in task duration and cost estimates: Fusion of probabilistic forecasts and deterministic scheduling; Journal of Construction Engineering & Management; 139 (5), 488-497. Keil, M.; Rai, A.; Liu, S.; (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. Keil M., Cule P., Lyytinen, K., and Schmidt, R., (1998) A framework for identifying software project risks. Communications of the ACM, 41, 11, 76-83. Kerzner, H. R. (2013). Project management: a systems approach to planning, scheduling, and controlling. Wiley. Koller, T., Lovallo, D., Williams, Z.,(2012) Overcoming a bias against risk; McKinsey Quarterly; 4, p15-17. Korrapati, R.; Kocherla, S.;(2010); A qualitative study on determining managerial styles for software development life cycle stages; Allied Academies International Conference: Proceedings of the Academy of Information & Management Sciences (AIMS); 14 (1), 54-57. Kwak, Y. H., & Stoddard, J. (2004). Project risk management: lessons learned from software development environment. Technovation, 24(11), 915-920. Kutsch, E.; Maylor, H.; Weyer, B.; Lupson, J.; (2011); Performers, trackers, lemmings and the lost: Sustained false optimism in forecasting project outcomes – Evidence from a quasi-experiment; International Journal of Project Management; Dec2011, 29 (8), 1070-1081. Laursen, E.; (2011); Organizational learning through development projects; International Journal of Manpower; 32(5/6); 567-580. Laurentiu, D.; Gabriela, D.; (2013); Sensitivity assessment modelling in European funded projects proposed by Romanian companies; Annals of the University of Oradea, Economic Science Series; 22 (2), 361-371. Lehtinen, T.O.A.; Mäntylä, M. V.; Vanhanen, J.; Itkonen, J.; Lassenius, C.; (2014); Percieved causes of software project failures – An analysis of their relationships; Information &Software Technology; 56 (6), 623-643. Legault, MJ.; Chasserio, S.; (2012); Professionalization, risk transfer and the effect on gender gap in project management; International Journal of Project Management; 30(6), p697-707. Lewin, M. D. (2001). Better software project management: A primer for success. John Wiley & Sons. Li, D. C.; Tsai, T. -I.; Shi, S.; (2009); A prediction of the dielectric constant of multi-layer ceramic capacitors using the mega-trend-diffusion in powder pilot runs: case study; International Journal of Production Research; 47 (1), p51-69. Little, R. G.; (2010); Towards a new Federal role in infrastructure investment: Using US sovereign wealth to rebuild America; Public Works Management & Policy; 14 (3), 288-306. March, J. G. & Z. Shapira, Z. (1987). Managerial Perspectives on Risk and Risk Taking. Management Science, 33, 1404-1418. Massey, G. R.; Kyriazis, E.; (2007); Interpersonal trust between marketing and R&D during new product development projects; European Journal of Marketing; 41 (9/10), 1146-1172. McFarlan, F. W., (1982). Portfolio Approach to Information Systems. Journal of Systems Management (January), 12-19. McManus, J. (2004). A stakeholder perspective within software engineering projects. In Engineering Management Conference, 2004. Proceedings. 2004 IEEE International (Vol. 2, pp. 880-884). IEEE. Australasian Journal of Information Systems Volume 18 Number 3 2014 189 McManus, J.; (2003); the application of risk planning in software development projects; Management Services; 47 (9), 16-18. Melnic, A.S.; Puiu, T.; (2011); the management of human resources within projects: the structures of the project team, the responsibility assignment matrix; Economy Transdisciplinarity Cognition; 14(1), 476-484. Mir, F. A., & Pinnington, A. H. (2014). Exploring the value of project management: linking project management performance and project success. International Journal of Project Management, 32(2), 202-217. Mouraviev, N.; Kakabadse, N.K.; (2014); Risk allocation in a public-private partnership: a case study of construction and operation of kindergartens in Kazakhstan; Journal of Risk Research; 17 (5), 621-640. Müller, R.; Turner, J. R..; (2005); the impact of principal-agent relationship and contract type on communication between project owner and manager; International Journal of Project Management; 23(5), 398-403. Olawale, Y. A.; Sun, M.; (2010); Cost and time control of construction projects: inhibiting factors and mitigating measures in practice; Construction Management & Economics; 28 (5), 509-526. Parker, D.; Charlton, J.; Ribeiro, A.; Pathak, R. D.; (2013); Integration of project-based management0020and change management intervention methodology; International Journal of Productivity & Performance Management; 62 (5), 534-544. Pavlak, A.; (2004); Project troubleshooting: Tiger teams for reactive risk management; Project Management Journal, 35(4), 5-14. Pieterse, M.; (2012), Critical success factors in information technology projects; UJ Library and Information Centre. Pinto, J. K., & Mantel Jr, S. J. (1990). The causes of project failure. Engineering Management, IEEE Transactions on, 37, 269-276. Project Management Institute, Inc. A guide to the project management body of knowledge (PMBOK® Guide), Fifth Edition (2013). Rivard, S., St-James, Y., & Cameron, A. (2011). Software project risk drivers as project manager stressors and coping resources. In System Sciences (HICSS), 2011 44th Hawaii International Conference on (pp. 1-10). IEEE. Rosenbaum, D.; The bold choice; (2005); CIO:18 (21), 40-44. Quartel, D.; Steen, M. W.A.; Lankhorst, M. M.; (2012); Application and project portfolio valuation using enterprise architecture and business requirements modeling; Enterprise Information Systems; 6 (2), 189-213. Rodriguez, E.; Edwards, J.; Koenig, D.; (2010); The board of directors, executives and risk knowledge management; Proceedings of the International Conference on Intellectual Capital, Knowledge Management & Organizational Learning. 394-404. Rosenkranz, C.; Corvera C. M.; Holten, R.; (2013), Language quality in requirements development: tracing communication in the process of information systems development; Journal of Information Technology (Palgrave Macmillan); 28(3), 198-223. Salmeron, J. L., & Lopez, C. (2012). Forecasting risk impact on ERP maintenance with augmented fuzzy cognitive maps. Software Engineering, IEEE Transactions on, 38(2), 439-452. Samáková, J.; Šujanová, J.; Koltnerová, K.; (2013); Project communication management in industrial enterprises; Proceedings of the European Conference on Information Management & Evaluation; 155-163. Australasian Journal of Information Systems Volume 18 Number 3 2014 190 Sakthidaran, R. T. (2010). How can an acquirer mitigate risks in software engineering projects?; Open Software Engineering Journal, 4. Sang-Hoon K.; Elsaid, H. H. (1985);Safely margin allocation and risk assessment under the NPV method; Journal of Business Finance & Accounting; 12 (1), 133-144. Schmidt, R.; Lyytinen, K.; Keil, M.; Cule, P.; (2001); Identifying software project risks: An international Delphi study; Journal of Management Information Systems17 (4), 5-36. Scurr, C.; (1990); Management services and total quality management; Management Services; 34 (7), 16-18. Shiferaw, A. T.; Klakegg, O. J.; Haavaldsen, T..; (2012); Governance of public investment projects in Ethiopia; Project Management Journal; 43(4), 52-69. Sillars, D. N., & O’Connor, M. B. (2009). Risk-Informed Transit Project Oversight. Journal of Management in Engineering, 25(3), 106-114. Skyner, L.; (2006); A viable framework of private investment in the utility sector: An analysis of the 2005 RF law of concession agreement; Review of Central & East European Law; 31 (2), 155- 177. Smith, D., Eastcroft, M., Mahmood, N., and Rode, H., (2006);Risk factors affecting software projects in South Africa; South African Journal of Business Management; 2, 55-65. Sungmin Y.; Caldas, C. H. (2009); Analyzing decision variables that influence preliminary feasibility studies using data mining techniques; Construction Management & Economics; 27(1), 73-87. Stoneburner, G., Goguen, A., & Feringa, A. (2002). Risk management guide for information technology systems. NIST special publication, 800(30), 800-30. Swink, M. L.; Sandvig, J. C.; Mabert, V. A.; (1996); Customizing concurrent engineering processes: five case studies; Journal of Product Innovation Management; 13 (3), 229-244. Sykes, K.; (2014), Global jobs report: 6 sectors to watch; PM Network; 28 (1), p58-67. Tasevska, F.; Damij, T.; Damij, N.; (2014); Project planning practices based on enterprise resource planning systems in small and medium enterprises – A case study from the Republic of Macedonia; International Journal of Project Management; 32(3), 529-539. Tesch, D.; Timothy J. K.; and Mark N. F.; (2007); IT project risk factors: the project management professionals perspective; Journal of Computer Information Systems 47 (4) 61-69. Thakurta, R. (2013). Impact of Scope Creep on Software Project Quality. Vilakshan: The XIMB Journal of Management, 10, 37-46. Thal Jr., A. E.; Martínez, C.; (2011); Contingency action helps projects deal with unknown unknowns; sustainability is good news; Industrial Management; 53(6), 8. Thomas, S., & Bhasi, M. (2011). How does software project risk vary across projects? An exploratory study from India. International Journal of Intercultural Information Management, 2, 301-316. Thompson, B. (2000). Q-technique factor analysis: One variation on the two-mode factor analysis of variables. in L. Grimm & P. Yarnold (Eds.), Reading and understanding more multivariate statistics (pp. 207-226). Washington, DC: American Psychological Association. Tuman J., (1986), Success modeling: A technique for building a winning project team.; Proc., 18th Annual Seminar/Symposium, Project Management Institute, Montreal, Canada, 29-34. Veil, S. R.; Husted, R. A.; (2012); Best practices as an assessment for crisis communication; Journal of Communication Management; 16 (2), 131-145. Verner, J.M.; Brereton, O.P.; Kitchenham, B.A.; Turner, M.; Niazi, M.; (2014); Risks and risk mitigation in global software development: A tertiary study; Information & Software Technology 56 (1), p54-78 Australasian Journal of Information Systems Volume 18 Number 3 2014 191 Vizard, M.; (2008); Why there is no business continuity; Baseline, 88, 18-18. Wallace, L., Keil, M., & Rai, A. (2004). How software project risk affects project performance: An investigation of the dimensions of risk and an exploratory model. Decision Sciences, 35, 289- 321. Warkentin, M., & Willison, R. (2009). Behavioral and policy issues in information systems security: the insider threat. European Journal of Information Systems, 18(2), 101. Witt, E.; Liias, R.;. (2011); Comparing risk transfers under different procurement arrangements; International Journal of Strategic Property Management; 15 (2), 173-188. Yelin X.; Yujie L.; Chan, A.P. C.; Skibniewski, M. J.; Yeung, J.F. Y. (2012), A computerized risk evaluation model for public private partnership projects and its application; International Journal of Strategic Property Management. 16 (3), 277-297. Yong, H., Juhua, C., Zhenbang, R., Liu, M., & Kang, X. (2006, December). A neural networks approach for software risk analysis. In Data Mining Workshops, 2006. ICDM Workshops 2006. Sixth IEEE International Conference on (722-725). IEEE. Zavadskas, E. K.; Turskis, Z.; Ustinovichius, L.; Shevchenko, G.; (2011); Attributes weights determining peculiarities in multiple attribute decision making methods; Engineering Economics; 21(1), 32-43. Zellner, A. (1962). An efficient method of estimating seemingly unrelated regressions and tests for aggregation bias. Journal of the American statistical Association, 57, 348-368. Zhang, Y.; Fan, Z.P.; (2014); An optimization method for selecting project risk response strategies; International Journal of Project Management; 32 (3), 412-422. Zofi, Y.; (2012); Getting deliverables out the door, Industrial Engineer; 44 (7), 35-40. ACKNOWLEDGEMENTS The authors would like to sincerely thank the Editor– Dr. John W Lamp for his continuous support. The authors are also appreciative of the two anonymous referees for useful comments that helped to structure the paper better.