Available online at www.sciencedirect.com

International Journal of Project Management 30 (2012) 176–187www.elsevier.com/locate/ijproman

Impact of organisational climate and demographics on project specific risksin context to Indian software industry

Arpita Sharma a,⁎, Aayushi Gupta b,1

a Sr. Lecturer and Research scholar, Professional Development Department in Jaypee Institute of Information Technology, A-10, Sector 62, Noida, Indiab Head of the Department and Associate Professor, Professional Development Department in Jaypee Institute of Information Technology A-10, Sector 62, Noida, India

Received 19 October 2010; received in revised form 23 March 2011; accepted 17 May 2011

Abstract

Software development in an organisation is often delimitedwith a number of risks at bothmacro andmicro level. Numerous researchers have focusedon abrogating these risks by advocating various mitigation strategies at organisational and technological levels. However, the understanding of howdemographics and organisation climate factors can reduce the software risks is largely anecdotal. It is a well known fact, that organisation climateinfluences the individual's ability in perceiving the risks affecting the software projects. The present study conducted on 300 software practitioners, aimsto identify organisational climate dimensions and risk dimensions in Indian software industry through factor analysis. It also establishes empiricalrelations between the two dimensions with the help of regression analysis. This research is useful for both academicians and practitioners who arestruggling to ensure success of the project by developing novel approaches for mitigating risks in software projects.© 2011 Elsevier Ltd. PMA and IPMA. All rights reserved.

Keywords: Organisation climate; Project specific software risks; Perspectives; Strategy; Managing projects

1. Introduction

The software and services industry in India has become agrowth engine for the economy, contributing significantly to theincrease in the GDP, urban employment and exports, to achievethe vision of authoritative and resilient India. Today, the Indiansoftware industry contributes 5.8% towards GDP with 45% ofincremental urban employment (both direct and indirect) and isexpected to grow by 16% and log revenues of USD 60 billion in2010 (Nasscom, 2009). The Indian software industry enjoys avery distinct advantage of a stable political environment,favourable government policies, a large base of English speakinggraduates, healthy relationship with existing global clients,telecom infrastructure and NASSCOM (National Association ofSoftware and Services Companies, a strong industry lobbyingbody) (Budhwar, 2005).

⁎ Corresponding author. Tel.: +91 9810723221.E-mail addresses: send2arpi@gmail.com (A. Sharma),

aayushi.gupta@jiit.ac.in (A. Gupta).1 Tel.: +91 9811377591.

0263-7863/$ - see front matter © 2011 Elsevier Ltd. PMA and IPMA. All rights rdoi:10.1016/j.ijproman.2011.05.003

It seems that the Indian software industry is experiencing asmooth sailing. But a close look reveals a completely differentpicture; high level of attrition, lack of trained softwareengineers, miscommunication of requirements, and no or lessexperience in handling similar projects (Anudhe and Mathew,2009; Gopal et al., 2002; Nidomolu and Goodman, 1993) aresome of the issues that are affecting the budget (cost overruns),schedule (late deliveries) and the quality (poor reliability anduser dissatisfaction) of the product and services being offered bythe Indian software companies.

Numerous researches have been conducted on identifying thecauses of failure or delay of the software projects and equalamount of time has been spent on recommending methods andmodels to combat these causes (Anudhe and Mathew, 2009;Costa et al., 2007, Gopal et al., 2002; Hoodat and Rashidi, 2009;Kwak and Stoddard, 2004; Nidomolu and Goodman, 1993;Ropponen and Lyytinen, 2000). In India, most of the studiesconducted have focused on the outsourcing aspect of the Indiansoftware industry, where various issues such as cross culturalissues, macroeconomic issues and project specific issues inoutsourcing have been detailed out (Anudhe and Mathew, 2009;

eserved.

177A. Sharma, A. Gupta / International Journal of Project Management 30 (2012) 176–187

Babar et al., 2007; Delmonte and McCarthy, 2003; Krishna et al.,2004; Nicholson and Sahay, 2001; Rainer and Hall, 2004; Tafti,2005). However, not much work has been done on variousdimensions relating to software development work in India.Software development is no doubt a part of outsourcing but still isone of the major revenue generating sources of most of the Indiansoftware companies. Arora and Athreye (2001) and Athreye(2005) have tried to identify various issues impacting the Indiansoftware companies both at macro, micro and project specificlevel. However, a comprehensive list of risks affecting theSoftware Development Life Cycle in Indian software industry isstill missing.

During the literature review, one interesting aspect that cameacross was the provision of a resilient organisational climate toensure the project's success. It is a well known fact that an open,trusting and robust climate in an organisation promotes freedomof expressions, mutual trust, team cohesiveness, team memberproximity, team autonomy, domain-relevant and creative-thinking skills. These to a great extent affect the individual'sability in perceiving the issues or risks affecting the softwareprojects.

Numerous studies have pointed out the effect of organisation'sclimate on the motivation, job satisfaction and the overallperformance of the software developers and the project's outcome(Doherty and King, 2003; Faraj and Sambamurthy, 2006;Geethalakshmi and Shanmugam, 2008; Warkentin et al., 2009and Xu and He, 2008). But there are hardly any empirical studiesthat identify the key organisational climate factors that contributetowards the project's success in the Indian context. Moreover, notmuch work has been done to elicit out any relation between theorganisational climate factors and the software risk factors.Therefore, there is a dire need for a systematic and comprehensivework that studies the moderating affect of organisation's climateon the project specific risk factors.

Therefore, the present study aims to identify the projectspecific risks affecting the Indian software industry, and studythe impact of organisational climate factors in annihilating theseproject specific risks.

2. Research problem and design

2.1. Related research

2.1.1. Software project risksSoftware project risk has long been claimed to be amajor cause

of project failure and empirical evidence exists to support it, withhigh levels of risk being associated with undesirable projectoutcomes such as low software quality, delays and budgetoverruns (Bannerman, 2008; Keil et al., 2004;Masri and Rivadry,2010; Wallace et al., 2004). The extant literature has produced anumber of conceptual frameworks to explain different types ofsoftware development risk, risk management strategies andmeasures of software project performance (Arshad et al., 2007;Baccarini et al., 2004; Bannerman, 2008; Boban et al., 2003;Costa et al., 2007; Ropponen and Lyytinen, 2000; Shahzadand Safvi, 2010; Wallace et al., 2004). Literature review hasalso shown that the risk factors change overtime due to the

development of technology and organisations. That is whyresearchers should, from time to time, conduct rigorous riskstudies. As a result, there have been various lists of risk factorswith some similarities and some differences (Arshad et al., 2007).Researchers like Boehm (1989), Oz and Sosik (2000), Ropponenand Lyytinen (2000), Schmidt et al. (2001), Jiang and Klein(2001), Addison and Vallabh (2002), Smith et al. (2006), Deyet al. (2007), Verner et al. (2007), Zhou et al. (2008), Bannerman(2008), Iacovou and Nakatsu (2008) and Anudhe and Mathew(2009) have time and again identified list of various risk factorsaffecting the success of the software projects. Some of theseresearchers have used case study data to discuss the key risksimpacting the projects due to the non use of risk managementprinciples (Anudhe and Mathew, 2009; Dey et al., 2007; Zhouet al., 2008).Whilst some have used various statistical measures toidentify the risks and propose their mitigation strategies (Chenand Huang, 2009; Engel and Last, 2007; Neumann, 2002;Ropponen and Lyytinen, 2000). Overall, these studies provideilluminating insights into critical risks and their mitigation, but areweak in explaining the true impact of risk management principlesso elaborated in practise. A few studies have even gone further toestablish systematic models of risk management (Lyytinen et al.,1998; Mathiassen et al., 1995). They all conclude that riskmanagement efforts reduce the exposure to software risk and canthereby increase software quality and improve software develop-ment. However, due to dynamic attribute of the software develop-ment and frequently changing technology it becomes necessaryfor researchers to reassess and enhance the studies on risk iden-tification and management.

2.1.2. Organisational climateIn project management, the trend is to focus on the technical

issues of the project, the timeline, the project plan, the resources,budget etc. When in fact, if a project is going to fail, in most casesa good deal of the problem can be traced back to leadership, lackof teamwork and other “soft” or cultural issues (Cornelius, 2006).Diverse literature is also available which points out the effect oforganisation's climate factors on the success of the project.Doherty and King (2003), Faraj and Sambamurthy (2006),Warkentin et al. (2009), Xu and He (2008), Geethalakshmi andShanmugam (2008), Woodruff (1990), McLean et al. (1996),Rasch and Henry (1992) have pointed out the effect oforganisation climate on the motivation, job satisfaction and theoverall performance of the software developers and the project'soutcome. According to Chan et al. (2008), Aladwani (2002), andYen et al. (2008), developing organisational citizenship behav-iours, support technologies, management advocacy, clear goals,feedback and team autonomy are the key to software projectsuccess. On the other hand, Doherty and King (2003) andWarkentin et al. (2009) advocates that organisational risksstemming from organisational culture, structure and businessprocesses impacts the technical software development issues,creating a wide range of potential trouble points. Thus, organisa-tions play a very crucial role in ensuring the success of the projectby providing the correct set of tools needed to control andalleviate the impact of the risk factors on the project.

178 A. Sharma, A. Gupta / International Journal of Project Management 30 (2012) 176–187

All these studies provide great insight into the factors affectingthe success of the software projects. However, the understandingof how demographics and organisation climate factors can reducethe software risks is largely anecdotal.

2.2. Research problem

As already pointed out, high level of attrition, lack of trainedsoftware engineers, and miscommunication of requirements aresome of the common risk factors affecting the success of theIndian software projects. Numerous researches have beenconducted in identifying the risks and causes of failure of thesoftware projects in India. Arora and Athreye (2001), Athreye(2005), Anudhe and Mathew (2009) etc. have tried to identifyvarious risks impacting the Indian software companies at macro,micro and project specific level. However, they have mainlyfocused on the risks affecting the offshore IT outsourcing.Outsourcing is just one aspect in software development; thereare a number of in-house developments that also take place inIndia. Therefore, a comprehensive list of risks affecting thesoftware development cycle in the Indian software industry isnecessary to get an overview of the risks that impact thesoftware development projects. Moreover as already discussed,the organisation climate factors to a great extent affect theindividual's ability in perceiving the risks affecting the softwareprojects. But not much work has been done to elicit out anyrelation between the organisation climate factors and thesoftware risk factors (Warkentin et al., 2009).

The present study has the following objectives:

1. To identify the project specific risk factors affecting the softwareprojects in India.

2. To identify the organisational climate factors present in theIndian software companies.

3. To investigate the effect of the demographic characteristicsand organisational climate dimensions on the software riskdimensions.

Based on the above objectives, a hypothesis has been framedwhich is presented below between organisation climate,demographics and software risk dimensions.

H1. The demographic variables and organisational climatedimensions affect the project specific risk in the software projects.

2.3. Research methodology

A systematic and coherent approach was adopted for theresearch study. First and foremost, based on an in-depth discussionand exhaustive literature review, the objectives of the study werechalked out. This was followed by in-depth interviews anddiscussions with 40 software project managers to gauge the riskfactors and organisational climate factors that affected the successof their last executed project. The project managers in the interviewwere specially asked to identify the critical risk factors affecting theSoftware Development Life Cycle and also key out theorganisational climate factors which they perceive were present

extensively in their organisations during the execution of thesoftware projects. Based on the perception of the project managersin the pilot study and in-depth literature review, an exhaustive listof 23 risk factors and 17 organisational climate factors wereidentified. These itemsweremeticulously drawn out after thoroughinterviews and comprehensive literature review, thus the list is all-inclusive. Based on these 23 risk items and 17 organisationalclimate items, a questionnaire was prepared. The questionnaire wasintricately designed to tap the information about i) the personalcharacteristics of the respondents viz. designation, age and totalexperience, ii) the risk factors impacting the success of the lastexecuted project and finally iii) the organisational climate factorsthat were present during the last executed project.

For identifying the software risk factors, the respondentswere asked to rate the impact of risks (23 items) on the successof their last executed project. Although the software risk hasbeen defined in various ways, however for the present study, therisk has been defined as the probability-weighted impact of anevent on a project (Bannerman, 2008; Boehm, 1989; Charetteet al., 1997). It must be noted here that only project specificsoftware risks have been taken into consideration for the study.The project specific risks are those risks that are present in theSoftware Development Life Cycle and affect the projectdelivery. All the items were put on a five-point scale rangingfrom far too much effect to no effect on the success.Respondents indicated no effect with the risk if that threat didnot exist in their project or the impact was very trivial.Similarly, the threat having far too much effect indicated thatthe impact of this risk was very severe and right mitigationtechnique could not be used to reduce the impact. For gaugingthe information about the organisational climate factors,respondents were asked to rate the organisational climatefactors (seventeen variables) present during the last executedproject. For the present research, organisation climate has beendefined as the perceived attributes of an organisation and itssub-systems as reflected in the way an organisation deals withits members, groups and issues (Litwin and Stringer, 1968). Afive-point Likert scale was designed to gauge the responses. Thescale ranged from never to always present.

The study aimed at employees working in the softwarecompanies in India. For the data collection 32 companies wereselected randomly from the four major IT hubs of India viz. NCR(Delhi, Gurgaon, Noida, Faridabad), Hyderabad, Chennai andBangalore, with eight from each hub through random sampling. Atotal of 900 questionnaires were sent to these 32 companies with arequest to get these filled from the software professionals havingan experience of more than 4 years of handling software projects(preferably project managers and above). Only 340 filled inquestionnaires were received out of which only 300were found tobe fully filled, the other 40 were discarded due to incompleteinformation. Statistical Package for the Social Sciences (SPSS)version 17.0 was used for the statistical analyses.

3. Analysis and findings

The data obtained from the field survey was analysed inseveral steps. Firstly, the major software risk dimensions and

179A. Sharma, A. Gupta / International Journal of Project Management 30 (2012) 176–187

organisational climate dimensions were identified using factoranalysis. Principal component analysis (PCA) was used as themethod of extraction and varimax was used as the rotationmethod. Secondly, correlation and regression analysis wereconducted to determine the effect of demographics and organisa-tional climate dimensions on the software risk dimensions.

To test the validity of the instrument, Cronbach alpha andKMO (Kaiser–Meyer–Olkin Measure of Adequacy) tests werecomputed. The value of Cronbach alpha came as 0.956 and 0.903for the risk variables and the organisational climate variablesrespectively, thus the instrument was considered reliable for thestudy. Whilst the Kaiser–Meyer–Olkin Measure of SamplingAdequacy (KMO) value for the risk variables and organisationalclimate instrumentwas 0.916 and 0.817 respectively, which againare accepted as good values (Rubin and Babbie, 2002).

The analysis below presents the profile of the respondents,followed by identification of risks and organisation climatedimensions using factor analysis and finally ending with theregression model.

3.1. Personal profile of the respondents

The first section of the instrument gathered informationabout the personal profile of the respondents which includeddesignation, total experience and age. Since the questionnairewas deliberately administered on IT professionals withexperience of more than 4 years in handling software projects,the respondents were primarily project leads and above. Out of300 respondents, 141 (47%) were primarily project managers,senior managers, account managers etc. Whilst 43 respondents(14%) were from the team of top management (Chief OperatingOfficer, Head IT, Director, Chief Executive Officer). In terms oftotal experience, 235 (78.3%) respondents had total experienceof less than 15 years, with almost 37.3% lying in the range of 4–9 years of experience in software projects. Only 65 (21.7%)respondents had more than 14 years of experience, mainlybelonging to the senior management team. Finally, in terms ofage of the respondents, 124 (41.3%) belonged to the age groupof 31 to 35. This category was strictly dominated by projectmanagers, technical managers and senior project managers.

Thus, it can be seen from the demographics that the samplewas dominated by project managers and senior project managers.

3.2. Identification of risk dimensions

Since the risk variables were large in number and were inter-related, factor analysiswas done to extract the factors affecting thesuccess of the projects. Principal Component Analysis (PCA)wasthe method of extraction. Varimax was the rotation method. Asper the Kaiser criterion, only factors with eigenvalues greater than1 were retained (Gorsuch, 1983; Kaiser, 1960). Four factors in theinitial solution had eigenvalues greater than 1. Together, theyaccounted for almost 67% of the variability in the originalvariables, which can be regarded as well beyond sufficient. Theitems falling under each of these factors were then dealt with quiteprudently. As is clear from Table 1, 9 of the items loaded on onlyone factor and seven items on another factor. The rest of the

factors had 3 or 4 items loaded on them. Overall, this resulted in areasonably clean and easy to interpret model.

The four extracted risk components are:

1. SRS variability risk2. Team composition risk3. Control process risk4. Dependability risk

The factors extracted for further study are shown in Table 1.These 4 factors that were extracted included the items whichhave loadings of more than 0.5 and have been referred as therisk dimensions in further analysis. The explanation of all thesefour dimensions is as follows.

3.2.1. SRS variability riskAs is clear from Table 1, the first factor identified through

factor analysis included a number of risks related to requirementvariability; thus accordingly, the first factor was named as theSoftware Requirement Specification (SRS) variability risk factor.The first step for any project is to gauge correct requirements fromthe client. The problems in the first step will definitely result indelay or failure in the extreme cases. Quite often it is observed thatlanguage problems and lack of expertise in handling similarprojects, affects the project manager's capability in gaugingcorrect set of requirements. Besides this, lack of client ownershipand lack of drive to specify requirements is a major contributor tovague requirements and not enough clarifications is done to de-bottleneck them in time. Researchers even state that the projectmanagers fail to make correct estimation in the initial stages of thesoftware development and sometimes distort or become toooptimistic, thus creating gross estimation errors (Keil et al., 2007;Smite, 2006; Snow et al., 2007). Thus it can be seen, how crucial itis to understand the requirements correctly for the success of theproject.

3.2.2. Team composition riskThis emerged as the second factor and includes a number of

risks related to the teammembers responsible for the developmentand execution of the project. The lack of top management supportand unavailability of a competent project manager are the majorcontributors to this risk. Apathy on the part of the topmanagementwill result in hiring of an inexperienced team or a diverse team.Further, if the top management is not keen in investing in trainingor hiring the subject matter expert, it will result in lack of domainexpertise which can create problems for the project (Barki andHartwick, 1989; Nah et al., 2001). In fact, as per the discussionsheld with the project managers of the Indian software companies,lack of technical expertise is one of the major issues in most of theprojects handled by the Indian software companies. Besides lackof interest of the senior management, project manager is alsoresponsible in contributing to the team composition risk. If themanager is inept in handling the team issues it is bound to createdissatisfaction amongst team members resulting in low morale,lack of commitment and finally turnover (Bosco, 2004; Dey et al.,2007; Faraj and Sambamurthy, 2006). It is the job of the managerto plan well in advance the time and the type of resources needed

Table 1Factor pattern matrix: risk factors affecting the success of the project.

Items Factor 1 Factor 2 Factor 3 Factor 4

Working with inexperienced team 0.206 0.651 0.071 0.266

Delay in recruitment and resourcing 0.646 0.508 −0.08 0.162

Less or no experience in similar projects 0.604 0.384 0.062 0.183

Insufficient testing 0.19 0.508 0.556 −0.201

Team diversity 0.235 0.65 0.346 −0.001

Lack of availability of domain expert 0.014 0.761 0.238 0.281

Lack of commitment from the project team 0.429 0.628 0.299 0.131

High level of attrition 0.446 0.613 0.21 0.062

Estimation errors 0.687 0.234 0.329 0.106

Inaccurate requirement analysis 0.786 0.248 0.249 0.127

Lack of top management support 0.268 0.561 0.269 0.399

Low morale of the team 0.268 0.596 0.221 0.313

Miscommunication of requirements 0.765 0.225 0.304 0.186

Conflicting and continuous requirement changes 0.789 0.12 0.218 0.231

Language and regional differences with client 0.612 0.138 0.501 0.242

Lack of client ownership and responsibility 0.533 0.262 0.488 0.303

Inadequate measurement tools for reliability 0.28 0.233 0.486 0.578

Third party dependencies 0.25 0.196 0.099 0.803

Inability to meet specifications 0.324 0.408 0.312 0.598

Inaccurate cost measurement 0.635 0.153 0.48 0.263

Poor code and maintenance procedures 0.342 0.29 0.716 0.201

Poor documentation 0.194 0.227 0.733 0.251

Poor configuration control 0.394 0.355 0.529 0.302

Greyed entries denote the entries that loaded i.e., have a high correlation with factors defined in the column.

180 A. Sharma, A. Gupta / International Journal of Project Management 30 (2012) 176–187

for the project, failing to do so results in project delays andescalation of cost and time.

3.2.3. Control processes riskThis factor included all the risks related to the control

mechanism of the project. To enable any changes successfully,the developer must know the configuration of the system and howchanges will affect the system. For this an up-to-date documen-tation and configuration control is extremely important (Ozoa,2006; Sabherwal et al., 2003). Beside this, it has also beenobserved that the software developer does not perform adequatetesting. After a detailed discussion with the quality analyst of areputed company in Noida, it was found that lack of time anddifficulty in coordinating tests, as different members of themaintenance team are working on different problems at the sametime, were the primary reasons for the same. This is especially truefor the Indian software companies.KavitakRamShriram, founder-director of Google said that “Indian IT professionals deliver lowquality application software that needs thorough testing”. Thus,this is a very crucial risk that affects the success of the project.

3.2.4. Dependability riskDependability risk was the name given to the last factor. The

items included in this are the third party dependencies, inability to

meet specifications and inadequate measurement tools forreliability. It is extremely vital for a software project to bedependable and reliable. Software dependability is defined as theability to avoid service failures that are more frequent and moresevere than is acceptable. Dependability is a broad term whichincludes availability, reliability, safety, integrity and maintainabil-ity of the software (Avizienis et al., 2004). For the successfulcompletion of a project, all components (hardware and software)must be available at the right time and at the right place. Sometimestomake things easier, a part of the project is outsourced to the thirdparty vendor. It has often been observed, especially in the Indiansoftware industry, that even when the project is delivered on timeyet it fails on reliability tests which means it fails to meet thedesired quality standards. Many reasons have been attributed tothis phenomenon by the Indian IT professionals. These areinability of the third party vendor to meet the specifications, wrongchoice of the sub-contracting vendor, or third party component notreliable. These findings are in conformity with studies of Pan(1999), Krasner (1998), and Ropponen and Lyytinen (2000).

3.3. Identification of organisational climate dimensions

Since the organisational climate factors were large in numberand were inter-related, factor analysis was done to extract the

181A. Sharma, A. Gupta / International Journal of Project Management 30 (2012) 176–187

factors responsible for the success of the software project. Asimilar approach using PCA was used for extracting organisa-tional climate factors. Four factors emerged from the factoranalysis as shown in Table 2.

The four organisational climate dimensions extracted fromthe analysis are:

1. High standards of work tasks2. Effective supervision3. Intrinsic fulfilment4. Role clarity

3.3.1. High standard of work taskThis name was given to factor 1. The items that strongly

correlated with this factor were adequate tools and technologiesneeded for performing work, work tasks were completed on time,there was a good balance between work and personal life, therewas fair and just treatment of the employees by the management,high standards of excellence in service and delivery were set bysenior management and there was clear understanding of worktasks which were to be performed. One thing that was common inall these variables is high standards of work task maintained bythe respondents whilst executing the project. High standard ofwork task not only encompasses quality of work done but also thelevel of commitment of the employees, clear definition of worktasks and life interest and work compatibility. A project can besuccessful only when the team members feel connected with theproject (Xu and He, 2008). When there is group “ownership,”project team members are more likely to treat the plan andmilestones seriously and put forth the necessary effort to get thework done. The presence of a fair and just treatment of the

Table 2Factor pattern matrix: organisational climate factors responsible for the success of th

Items

There was clear understanding of roles and responsibilities within the group.

There was full utilization of my skills and abilities in the project.

There were opportunities to further develop my skills and abilities.

There were challenging tasks in my job role.

Employees consulted with one another when they needed support.

I felt valued as an employee.

There was a good balance between work and personal life.

High standards of excellence in service and delivery were set by senior management.

There was fair and just treatment of the employees by the management.

My direct supervisor gave me helpful feedback on how to be more effective.

My direct supervisor listened to my ideas and concerns.

My direct supervisor appreciated the work I did.

There was clear understanding of work tasks which were to be performed.

Everyone took responsibility for his/her actions.

Work tasks were completed on time.

There were adequate tools and technologies needed for performing work.

Our products/services met our customers' expectations.

Greyed entries denote the entries that loaded i.e., have a high correlation with facto

employees by the management plays a very crucial role inmotivating the employees to give their best. Studies have shownthat effective management of the project, team work, teamautonomy, creative-thinking skills, team coordination, usingsupport technologies, identifying clear goals, and assigning tasksto competent team members have been proven to engender thesoftware project success (Aladwani, 2002; Crowston andKammerer, 1998; Hoegl et al., 2007; Renn, 2003).

3.3.2. Effective supervisionThis name was given to factor 2. All the items that strongly

associated with this factor are my direct supervisor listened to myideas and concerns, my direct supervisor gave me helpfulfeedback on how to be more effective, my direct supervisorappreciated the work I did and I felt valued as an employee. Allthese items had one commonality and that is effective andfacilitative supervision. Extraordinary demands are placed onsoftware personnel—demands that require extraordinary com-mitments in order to accomplish the task at hand. Generating thislevel of commitment through the process of team building is aprimary responsibility of any supervisor (Adams and Adams,1997). Finding a person who can handle these challengessuccessfully is not easy. Few people have the qualifications andattitudes necessary to succeed in managing complex projects.Having a certain level of technical competence is helpful, butmanagerial and interpersonal skills are the most importantattributes of an effective supervisor. Previous studies (Espinosaet al., 2006; Luthans et al., 2008; Yen et al., 2008) have laid greatemphasis on characteristics of an effective supervisor, teamcommitment and the success of the software projects. Therefore,finding the right minded person, who values the team members,

e software project.

Factor 1 Factor 2 Factor 3 Factor 4

0.418 0.101 0.146 0.668

0.222 0.189 0.713 0.168

−0.021 0.265 0.779 0.199

0.034 0.142 0.748 0.181

0.004 0.039 0.219 0.824

0.228 0.555 0.402 −0.136

0.671 0.322 −0.13 0.222

0.564 0.428 −0.076 0.282

0.599 0.484 −0.064 0.197

0.149 0.832 0.177 0.065

0.112 0.848 0.156 0.154

0.116 0.826 0.309 0.059

0.489 0.4 0.307 0.207

0.454 0.156 0.313 0.657

0.784 −0.024 0.358 0.117

0.79 0.045 0.181 0.028

0.561 0.16 0.591 0.09

rs defined in the column.

182 A. Sharma, A. Gupta / International Journal of Project Management 30 (2012) 176–187

listens to their ideas, and facilitates their development, is verycrucial.

3.3.3. Intrinsic fulfilmentThis name was given to Factor 3. The items that were strongly

associated with factor 3 were opportunities to further develop myskills and abilities, there were challenging tasks in my job role,there was full utilisation of my skills and abilities in the projectand our products/services met our customers' expectations. Allthese items rated by the respondents had one thing in common andit was the intrinsic fulfilment. Intrinsic fulfilment is when anindividual is motivated by internal factors, as opposed to externaldrivers of motivation. Intrinsic motivation is the means by whichthe potent wellsprings of human energy and creativity are directedtoward people's desired goals (Boehm, 1981). Thus, intrinsicmotivation drives one to do things from the soul. Factors likegrowth opportunities, substantial learning during and after theproject, challenging tasks and feeling of self-fulfilment arouse theinstinct in an individual internally. Autonomy, proper feedback,intellectually challengedwork enables the teammembers to bringout the best in them. McConnell (1996) has also cited in his studythat IT professionals place higher value in the intrinsic value ofthe work itself rather than in extrinsic factors, which includecompensation, working conditions and appropriate technicalresources. Much of the research that focused on the practitioner'sperception of software project success, explored to some extentemployee motivation (McConnell, 1996; Procaccino, 2006;Verner et al., 2010). Therefore, project managers need to establisha vision for the development team, hold the team accountable forresults, delegate tasks to the team in a manner that are“challenging, clear and supportive” and remove barriers to teamproductivity when necessary (Demarco and Lister, 2003; Jiangand Klein, 2000; Procaccino et al., 2002).

3.3.4. Role clarityThis name was given to Factor 4. The items that were

strongly associated with factor 4 are: employees consulted withone another when they needed support, there was clear under-standing of roles and responsibilities within the group andeveryone took responsibility of his/her actions. All these itemsrated by the respondents had one thing in common and that isclarity in roles and responsibilities. Role clarity is defined as the“fit between the amount of information that a person has and theamount he (or she) requires to perform the role adequately”(Kahn, 1973). Opportunities realised or opportunities lost canbe linked to how well an individual grasps his/her role and thelevel of commitment to accountabilities, even the slightestvagueness here can hurt an entire team's ability to meet itsobjectives. Without a clear articulation of roles, a team can besent sputtering whenever a new idea or problem presents itself.However, a clear and lucid definition of roles and responsibilitiespromotes autonomy, ownership, job satisfaction, self-account-ability and commitment towards the project and organisation(Braun andAvital, 2007). Numerous studies have been conductedon establishing relationship between role clarity, job satisfactionand commitment towards the project and organisations (Abramis,1994; Morrison, 1993; Whitmaker and McKinney, 2009).

After identifying the risk and organisation climate di-mensions, the next step involved conducting a regressionanalysis to validate the following hypothesis:

H1. The background variables and organisational climate di-mensions affect the project specific risk in the software projects.

Based on the factor analysis, the main hypothesis was sub-divided into 4 sub hypotheses, which were tested individuallyusing stepwise regression. The hypotheses are as follows:

Hypothesis related to SRS variability risk:

H1a. The background variables and the organisational climatedimensions affect the SRS variability risk.

Hypothesis related to team composition risk:

H1b. The background variables and the organisational climatedimensions affect the team composition risk.

Hypothesis related to control processes risk:

H1c. The background variables and the organisational climatedimensions affect the control process risk.

Hypothesis related to the dependability risk:

H1d. The background variables and the organisational climatedimensions affect the dependability risk.

3.4. Correlates and impact assessment of organisational climatedimensions and demographics on the software risk dimensions

In order to identify a relation between demographic char-acteristics and organisational climate with the software riskdimensions, correlations were computed. The independent vari-ables were the three demographic characteristics namelydesignation, total experience and age and four organisationalclimate dimensions namely high standards of work tasks,effective supervision, intrinsic fulfilment and role clarity. Whilstthe dependent variables were four software risk dimensionsnamely SRS variability risk, team composition risk, controlprocess risk and dependability risk. The correlation coefficients ofthe seven independent variables and the four dependant variableare shown in Table 3.

Table 3 shows all the correlation between the seven inde-pendent variables with the four risk dimensions. As is clear fromTable 3, all the personal characteristics have a significantcorrelation with all the dependent variables. All the demographicvariables negatively correlate with the four risk dimensions. Thismeans that the perception about the risks greatly vary as theemployees move ahead in their career and gain more experience.A negative correlation indicates that the project managers andsenior project managers with an experience of 11–15 yearsperceive these risk factors as having less impact on the successthan perceived by the project leads with an experience of 4–7 years. Whilst on the other hand, out of the four organisationalclimate dimensions only few dimensions show a significantrelation with the four risk dimensions. Out of which, role clarityshows a significant negative correlation with two dimensions of

Table 3Relationships (correlation coefficients) of demographics and organisational climate dimensions with the project specific risk dimensions. (N=300).

Demographics and organisational climate dimensions SRS variability risk Team composition risk Control process risk Dependability risk

Designation −0.340 ⁎⁎ −0.258 ⁎⁎ −0.283 ⁎⁎ −0.286 ⁎⁎Total experience −0.173 ⁎⁎ −0.174 ⁎⁎ −0.152 ⁎⁎ −0.255 ⁎⁎Age −0.224 ⁎⁎ −0.177 ⁎⁎ −0.172 ⁎⁎ −0.241 ⁎⁎Climate of high standards of work tasks 0.021 NS 0.037 NS 0.072 NS −0.063 NSClimate of effective supervision 0.100 NS 0.028 NS 0.053 NS 0.197 ⁎⁎

Climate of intrinsic fulfilment −0.082 NS −0.031 NS −0.108 NS −0.043 NSClimate of role clarity −0.191 ⁎⁎ −0.098 NS −0.110 NS −0.136 ⁎

⁎ Correlation is significant at the 0.05 level.⁎⁎ Correlation is significant at the 0.01 level.

183A. Sharma, A. Gupta / International Journal of Project Management 30 (2012) 176–187

risk, namely, SRS variability risk, and dependability risk whilsteffective supervision show a significant positive correlation withone dimension that is dependability risk.

3.4.1. Regression model for predicting the effect oforganisational climate dimensions and demographiccharacteristics on the software risk dimensions

This section works out the regression model of the de-mographics and organisational climate dimensions that impactthe project specific software risk dimensions. It was assumed thatthere is a linear relationship between the organisational climatedimensions, demographics and the software risk dimensions. Astepwise regression analysis was conducted with the dependentvariable as the four dimensions of software risk namely SRSvariability, team composition, control processes and dependabilityrisk, and the independent variables as the demographics andorganisational climate factors. It must be noted, that to avoid multi-collinearity, out of the three demographic characteristics, onlydesignation and total experience were taken as the independentvariables whilst age was ignored, as it showed a very highcorrelation with designation (0.690**) and total experience(0.782**). The regression models between the organisationalclimate factors and demographic characteristics with the SRSvariability risk, team composition risk, control processes risk anddependability risk have been examined in the following section.

3.4.1.1. SRS variability. A regression analysiswas conducted tocomprehend the impact of designation, experience and organisa-

Table 4Relationship between organisational climate dimensions and demographics with pro

Independent variables Dependent variable:SRS variability risk

Dependent variableteam composition

Beta Simple r t-value Beta Simple

Experience – – – – –Designation − .355 ⁎⁎ −0.340 ⁎⁎ 6.777 − .267 ⁎⁎ −0.258Role clarity − .276 ⁎⁎ −0.1908 ⁎⁎ 4.982 −.119 ⁎ −0.098Effective supervision − .177 ⁎⁎ 0.1002 NS 3.200 – –High standards of work tasks – – – – –Intrinsic fulfilment – – – – –Multiple R 0.44 0.28R2 0.19 0.08

⁎ Significant at 0.05 level.⁎⁎ Significant at 0.01 level.

tional climate factors on the SRS variability risk of the softwareproject. The equation which emerged after the process was asfollows. Table 4 summarises the determinants of the equation.

Y1 = 4:776−0:35X1−0:28X2–0:177X3

where,

Y1 SRS variability riskX1 designationX2 role clarityX3 effective supervision

The value of multiple R is 0.44 and the value of R square cameas 0.19. It states that 19% of the SRS variability risk can becontrolled by these factors. 19% is a significant value thatexplains the causes of this risk as only organisational climate hasbeen taken into consideration. The rest 81% can be attributed to somany other factorswhich are scattered and individually contributeonly little to the SRS variability risk. As can be seen from theabove equation, there is an inverse relationship between desig-nation and SRS variability risk (beta=−0.35), indicating thatteam members at the lower levels such as project lead, technicallead or senior software engineer perceive SRS variability riskas having a high impact on the project. This has also beenrecapitulated bymany researchers such asWarkentin et al. (2009)and Verner et al. (2007). Besides this, SRS variability getsaffected by two dimensions of organisation climate namely, roleclarity and effective supervision. A clear and lucid understanding

ject specific risk dimensions. (N=300).

:risk

Dependent variable:control processes risk

Dependent variable:dependability risk

r t-value Beta Simple r t-value Beta Simple r t-value

– – – – – – –⁎⁎ 4.784 − .281 ⁎⁎ −0.283 ⁎⁎ 5.119 − .308 ⁎⁎ −0.286 ⁎⁎ 5.827NS 2.133 − .232 ⁎⁎ −0.110 NS 3.474 − .164 ⁎⁎ −0.136 ⁎ 3.789

– – – – −.333 ⁎⁎ −0.198 ⁎⁎ 4.573– − .173 ⁎⁎ .0721 NS 2.580 − .179 ⁎⁎ −0.063 NS 2.497– – – – – – –

0.34 0.430.12 0.18

184 A. Sharma, A. Gupta / International Journal of Project Management 30 (2012) 176–187

of the roles and responsibilities enables the team members toperform their jobs with utmost care and consideration. Thus, witha beta value of −0.28 and a correlation coefficient of −0.19, bothsignificant at 0.01 level, this factor impacts significantly and quitelargely in controlling the SRS variability risk.

Effective supervision with a beta value of −0.177, significantat 0.01 level, contributes tremendously in reducing the SRSvariability risk. One of the major aspects of supervision is timelyand effective feedback in the initial stages of the project. Feedbackis a salient mean of guiding, motivating, and reinforcing effectivebehaviours within the team, thereby reducing detrimental effectson the project (London and Smither, 2002; Renn, 2003;Whitmaker and McKinney, 2009; Xu and He, 2008). To avoidpotential miscommunications and complexity, measures such asthe establishment of clear feedback mechanisms (such as weeklymeetings, face-to-face meetings, early prototyping) is a verycommon mitigation tool which must be used most effectively.Therefore, an appropriate and helpful feedback from thesupervisor reduces this risk to a great extent. Thus, the alternatehypothesis H1a is accepted.

3.4.1.2. Team composition risk. To gauge the impact oforganisational climate factors and the perception of the teammembers at various designation and experience on the teamcomposition risk, a regression analysis was conducted. Theequation which emerged after the process was as follows.Table 4 summarises the determinants of the equation.

Y2 = 4:152−0:27X1−0:12X2

where,

Y2 team composition riskX1 designationX2 role clarity

With multiple R of 0.28 and R square at 0.08, this risksignificantly gets affected by the presence of high degree of roleclarity and demographics in the organisation. The R square valueof 8% is a significant value that explains the impact of theindependent variables on team composition risk. It must be notedhere, that only a part of the internal aspect of the organisation hasbeen considered as independent variables. The environmentalfactors such as competition, political, technological, socio/cultural factors which may be contributing the rest 92% werenot taken for the analysis. The two variables that independentlycontribute towards the team composition risk are designation witha beta value of −0.27 and role clarity with a beta of −0.12. Thisindicates that as the employee moves ahead in his career the riskof working with inexperienced team or lack of commitment fromthe project team etc. is perceived as having less impact in theproject. Apart from this, role clarity with a negative beta of 0.12,significant at 0.05 level, contributes greatly in reducing the teamcomposition risk. Belbin (1981) has argued that team members'sense of commitment grows stronger as they better understandtheir own roles within the team. Role clarity takes on a greatersignificance since each person has to take on a definite task and

complete it so that the team as a whole can accomplish theimplementation effort, thereby, ensuring greater degree ofcommitment levels from the team. A project with a right mix ofteam members, wherein, each member is conscientious towardshis role and responsibilities is an ideal stage. Besides this, byhaving a free and open environment in the team, where teammembers can freely discuss and seek advice from each other, theteam composition risks can be eliminated. Thus, the alternatehypothesis H1b stating that organisational climate dimensionsand demographics affect the team composition risk is accepted.

3.4.1.3. Control processes risk. The third risk factor identifiedafter performing factor analysis was control processes risk. It washypothesised that robust organisational climate factors can reducethe impact of this risk. Further hypothesis was also maderegarding the perception of various demographic characteristicson this risk. A stepwise regression analysis was conducted foranalysing the relation between the control processes risk, fourorganisational climate factors and two demographic characteris-tics. Table 4 summarises the determinants of the equation.

Y3 = 3:743−0:28X1−0:22X2–0:17X3

where,

Y3 control processes riskX1 designationX2 role clarityX3 high standard of work tasks

As is clear from Table 4, with multiple R of 0.34 and R squarevalue of 0.12, the control processes risk is negatively affected bythe three independent variables namely designation, role clarityand high standard of work tasks. The analysis revealed theperception about the control processes risk at various designationlevels. With a beta of −0.28 and correlate coefficient of −0.283,both significant at 0.01 level, it shows that as the team memberclimbs the organisation's hierarchical ladder his/her perceptionabout the software risk changes and he starts perceiving controlprocesses risk as a controllable risk with less impact on project.Besides this, the empirical analysis also revealed the twoorganisational climate factors that impinge the control processesrisk. These two climate factors are role clarity and high standard ofwork tasks. High standards of excellence means adoption of wellplanned and formalised procedures such as benchmarking, sixsigma processes, total quality management and CMM level 5processes which are the highest accepted industry standardsworldwide. If an organisation adopts these, the risk of poorcontrol processes can be controlled to a great extent (Braun andAvital, 2007). Role clarity with a beta value of−0.232, significantat 0.01 level, and high standards of work tasks with a beta of−0.17, significant at 0.01 level, clearly indicates that the presenceof these two factors will enable the project manager and his teamto clearly define and follow the processes to be adopted forsuccessfully completing the project.

185A. Sharma, A. Gupta / International Journal of Project Management 30 (2012) 176–187

3.4.1.4. Dependability risk. A regression analysis was con-ducted to comprehend the perception of the demographiccharacteristics and understand the impact organisational climatefactors on the dependability risk of the software project. Table 4summarises the determinants of the equation.

Y4 = 3:985−0:31X1−0:33X2–0:16X3–0:18X4

where,

Y4 dependability riskX1 designationX2 effective supervisionX3 role clarityX4 high standards of work tasks

The value ofmultiple R is 0.43 and the value of R square is 0.18in the equation. It states that 18% of the dependability risk can becontrolled by these factors. The rest 82% can be attributed to somany other factors such as managerial issues, people issues,procedural issues and technical competency of the third partyvendors which individually contribute to the dependability risk ofthe software project. The first independent variable showing aninverse relation with dependability risk is designation. This meansthat as the employee climbs the organisational hierarchy his/herperception about the risk changes. Hence the perception of a projectmanager about the dependability risk is different from that of asenior software engineer. A negative beta (−0.308**) shows thatthe project manager perceives dependability risk as a controllablerisk with little impact on the project. Besides this, better clarity inroles, an adept supervisor and setting up of high standards of worktasks contributes positively in reducing the risk of dependability. Ifthe team member has a clear understanding of roles andresponsibilities and a will to accept his responsibilities, he willnotify the manager well in advance, in case he sees any deviationfrom the third party vendor, thus, reducing the risk ofdependability. Furthermore, it is extremely important for theorganisation to have a disciplined approach and a well laid downplan where the work is finished much before time and is tested forreliability before it is made available to the client (Schneidewind,2006). Finally, the presence of a proficient supervisor, who listensto the concerns of the teammembers and gives valuable and timelyfeedback, can to a great extent control the risk of dependability.Thus, role claritywith a beta of−0.16 (significant at 0.01 level) andcorrelations coefficient of −0.14 (significant at 0.05 level),effective supervision with a beta of −0.33 and correlationcoefficient of −0.198 (both significant at 0.01 level) and highstandards of work tasks with a beta of −0.18 (significant at 0.01level) contributes tremendously in reducing the dependability risk.

Based on the outcome of regression analysis and the results ofhypothesis tests, it can be clearly seen that the organisationalclimate factors affect the software risks. It can also be seen that notall of the organisational climate factors affect the risk factors.However, to state that the rest of the dimensions have no impacton the risks would be blatantly wrong. Even though no empiricalrelation could be established, yet after a detailed discussion withfew project managers of a reputed IT company it was found that

some of the organisational climate factors have an intrinsic effecton the project which cannot really be quantified. For example,intrinsic fulfilment factor of organisational climate did not showany relation with the risk dimensions. These are internal factorswhich if present in the project team will indirectly affect the riskfactors as team members will be motivated to work and give theirbest. Thus, it can be said that the background variables andorganisation climate has a profound effect on annihilating theproject specific software risks thereby ensuring the success of theproject to a great extent.

4. Research limitations

The research gauges the effect of demographics and organisa-tional climate dimensions on project specific risk. However, thestudy is limited on number of grounds. Firstly, the sample of thestudy consists only of the software projects executed by the Indiansoftware companies. Moreover, software projects have a numberof aspects technological, managerial, economic, political, socialetc., out of which only the managerial aspect of the softwareprojects has been looked into. It is also important to note that thestudy is limited to a sample size of 300 projects executed in anyone of the four major IT hubs of India. Moreover, the softwareprojects have been taken in general and have not been classifiedinto various categories like application development, ERP, SAPetc. thus limiting the scope of the study. In addition, only theproject specific risks have been considered. The project specificrisks emerge due to the factors affecting the project delivery.There are many macro level risks like economic, cultural, social,and people risks that affect the success of the project, which havebeen ignored in the present study. Therefore, the scope of thestudy is limited to the sample size and also to the selecteddimensions of success, risk and organisational climate factors.

5. Conclusion and recommendations

This research study uses survey data to explore the keyorganisational climate dimensions that affect the software riskdimensions using quantitative methods. The data collected from300 software professionals provided enough empirical informa-tion for statistical analysis to arrive at a number of conclusions.

The present study has made the following contributions. Firstof all, a comprehensive list of project specific risk dimensionsaffecting the software projects in India was prepared. Some ofthese risks identified were also present in studies conducted byNidomolu and Goodman (1993), Gopal et al. (2002), Anudheand Mathew (2009). Along with this, the Indian softwareorganisation's climate as perceived by the IT professionals wasalso explored and keyed out. A few of these factors are alsopresent in the studies done by Paul and Anantharaman (2004) andGeethalakshmi and Shanmugam (2008). A relationship betweenbackground variables, organisation's climate and software riskswere identified. It was found that most of the risk factors affectingthe Indian software companies can be controlled or annihilated byproviding clarity in roles and responsibilities and providing anenvironment where the employees or team members areencouraged to accept and own up the responsibility of their

186 A. Sharma, A. Gupta / International Journal of Project Management 30 (2012) 176–187

actions. Further, steps must also be taken to ensure that thesupervisor is not only technically trained but also possessmanagerial and interpersonal skills and acts as a facilitator ratherthan a dictator to the team members. Lastly, the organisationshould establish high standards of work task by taking up variouscertifications and practising them in the projects. The organisa-tions must establish an environment of internal audit reviews anddevote certain percentage of revenues in research, training anddevelopment of its employees. In order tomaintain high standardsof work tasks, the organisations must align the performanceappraisals of the team and the project manager with the trainingsand the conferences they have attended. This will ensure themaintenance of standards of excellence in delivery, therebyreducing the failures in the software industry.

In one of the interviews conducted, the client from U.S. of aCMM level 5 company located in Noida pointed out that

“The education on both employees and employers is neededto control the software risks. Management need to practisebetter people management skills and theory, they need totreat people as the most important resource and not treatthem as assets that are easily replaceable. Technology,tools, methodology, procedures are all have to be carriedout by people. People make or break projects and thereforepeople management skill is the most important and usefulskill to ensure project success.”

Thus, the key contribution of this research is the identifica-tion of the empirical relation between the organisational climatedimensions and the software risk dimensions. This research isespecially useful for the practitioner's community who arestruggling to ensure success of the project by developing novelapproaches for mitigating risks in software projects.

References

Abramis, D., 1994. Work role ambiguity, job satisfaction, and job performance:meta-analyses and review. Psychological Reports 75, 1411–1433.

Adams, J.R., Adams, L.L., 1997. The virtual project: managing tomorrow'steam today. PM Netw. 11 (1), 37–42.

Addison, T., Vallabh, S., 2002. Controlling software project risks: an empiricalstudy of methods used by experienced project managers. Proceedings ofSAICSIT. Port Elizabeth, pp. 128–140.

Aladwani, A., 2002. An integrated performance model of information systemsprojects. Journal of Management Information Systems 19 (1), 185–210.

Anudhe, M.D., Mathew, S.K., 2009. Risks in offshore IT outsourcing: a serviceprovider perspective. European management journal 27, 418–428.

Arora, A., Athreye, S., 2001. The Software Industry and India's EconomicDevelopment. UN WIDER.

Arshad, N.R., Mohamed, A., Matnor, Z., 2007. Risk factors in softwaredevelopment projects. Proceedings of the 6thWSEAS international conferenceon software engineering, parallel and distributed systems Corfu island, Greece,February 16–19.

Athreye, S., 2005. The Indian software industry and its evolving servicecapability. Industrial and Corporate Change 14 (3), 393–418.

Avizienis, A., Laprie, J.C., Randell, B., Landwehr, C., 2004. Basic concepts andtaxonomy of dependable and secure computing. IEEE Transactions onDependable and Secure Computing 1, 11–33.

Babar, M.A., Verner, J.M., Nguyen, P.T., 2007. Establishing and maintainingtrust in software outsourcing relationships: an empirical investigation.Journal of Systems and Software 80 (9), 1438–1449.

Baccarini, D., Salm, G., Love, P.E.D., 2004. Management of risks ininformation technology projects. Industrial Management & Data Systems104 (4), 286–295.

Bannerman, P.L., 2008. Risk and risk management in software projects: areassessment. The Journal of Systems and Software 81, 2118–2133.

Barki, H., Hartwick, J., 1989. Rethinking the concept of user involvement. MISQ. 13 (1), 53–63.

Belbin, R.M., 1981. Management Teams. John Wiley & Sons, New York.Boban, M., Pozgaj, Z., Sertic, H., 2003. Strategies for successful software

development risk management. Management 8 (2), 77–91.Boehm, B.W., 1981. Software Engineering Economics. Englewood Cliffs, NJ,

Prentice-Hall.Boehm (Ed.), 1989. Organisational Climate and Culture. Jossey-Bass, CA,

pp. 383–412.Bosco, G., 2004. Implicit theories of good leadership in the open-source

community Accessed: 22.08.2010 *http://opensource.mit.edu/papers/bosco.pdf.

Braun, F., Avital, M., 2007. Good project management practices drive more thanproject success: learning, knowledge sharing and job satisfaction in it projectteams. Proceedings of the 13th Americas Conference on InformationSystems at Colorado, August 9–12, pp. 1–11.

Budhwar, R., 2005. Indian software industry: moving up the value chain. www.fms.edu/downloads/conclub_ITinIndia-TheWayForward.pdf. Assessed on13th August 2010.

Chan, C.L., Jiang, J.J., Klein, G., 2008. Team task skills as a facilitator forapplication and development skills. IEEE Transaction on EngineeringManagement 55 (3), 434–441.

Charette, R.N., Adams, K.M., White, M.B., 1997. Managing risk in softwaremaintenance. IEEE Softw. 14 (3), 43–50.

Chen, J.C., Huang, S.J., 2009. An empirical analysis of the impact of softwaredevelopment problems factors software maintainability. The Journal ofSystems and Software 82 (6), 981–992.

Cornelius, E.T., 2006. Seven tactics to increase projects success. Collegiateproject services. http://www.collegiateproject.com/articles/SevenTactics.pdf. assessed 10th march 2010.

Costa, H.R., Barros, M.D.O., Travassos, G.H., 2007. Evaluating softwareproject portfolio risks. The Journal of Systems and Software 80, 16–31.

Crowston, K., Kammerer, E.E., 1998. Coordination and collective mind insoftware requirements development. IBM Syst. J. 37 (2), 227–245.

Delmonte, A., McCarthy, R., 2003. Offshore software development: is thebenefit worth the risk? Americas Conference on Information Systems(AMCIS) AMCIS 2003 Proceedings, pp. 1607–1613.

Demarco, T., Lister, T., 2003. Waltsing with Bears: Managing Risk on SoftwareProjects. Dorset Publishing Co, New York.

Dey, P.K., Kinch, J., Ogunlana, S.O., 2007. Managing risk in softwaredevelopment projects: a case study. Industrial management and Data Systems107 (2), 284–303.

Doherty, N.F., King, M., 2003. From technical change to socio-technicalchange: towards a proactive approach to the treatment of organisationalissues. Socio-technical and Human Cognition Elements of InformationSystems. Idea Group Publishing, Hershey, PA, pp. 22–40.

Engel, A., Last, M., 2007. Modeling software testing costs and risks using fuzzylogic paradigm. Journal of Systems and Software 80 (6), 817–835.

Espinosa, J.A., DeLone, W., Lee, G., 2006. Global boundaries, task processesand IS project success: a field study. Information Technology & People 19(4), 345–370.

Faraj, S., Sambamurthy, V., 2006. Leadership of information systemsdevelopment projects. IEEE Trans. Eng. Manag. 53 (2), 238–249.

Geethalakshmi, S.N., Shanmugam, A., 2008. Success and failure of softwaredevelopment: practitioners' perspective. Proceedings of the InternationalMulti-Conference of Engineers and Computer Scientists, VIMECS 1, 19–21.

Gopal, A., Mukhopadhyay, T., Krishnan, M.S., Goldenson, D.R., 2002.Measurement programs in software development: determinants of success.IEEE Trans. Softw. Eng. 28 (9), 863–875.

Gorsuch, R.L., 1983. Factor Analysis, 2nd ed. Erlbaum, Hillsdale, NJ.Hoegl, M., Ernst, H., Proserpio, L., 2007. How teamwork matters more as team

member dispersion increases. Journal of Product InnovationManagement 24(2), 156–165.

187A. Sharma, A. Gupta / International Journal of Project Management 30 (2012) 176–187

Hoodat, H., Rashidi, H., 2009. Classification and analysis of risks in softwareengineering. World Academy of Science, Engineering and Technology 56,446–452.

Iacovou, C.L., Nakatsu, R., 2008. A risk profile of offshore-outsourceddevelopment projects. Commun. ACM 51 (6), 89–94.

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

Jiang, J., Klein, G., 2001. Software project risks and development focus. ProjectManagement Journal 32 (1), 20–26.

Kahn, R.L., 1973. Conflict, ambiguity, and overload: three elements in jobstress. Occupational Mental Health. 3, 2–9.

Kaiser, H.F., 1960. The application of electronic computers to factor analysis.Educational and Psychological Measurement 20, 41–151.

Keil, M., Smith, H.J., Pawlowski, S., Jin, L., 2004. ‘Why didn't somebody tellme?’: climate, information asymmetry, and bad news about troubled projects.The DATA BASE for Advances in Information Systems. 35 (2), 65–84.

Keil, M., Paul, I.M.G., Mahring, M., 2007. Reporting bad news on softwareprojects: the effects of culturally constituted views of face-saving.Information of Systems Journal 17 (1), 59–87 2007.

Krasner, H., 1998. Looking over the legal edge of unsuccessful softwareprojects. Cutter IT Journal. 11 (3), 11–22.

Krishna, S., Sahay, S., Walsham, G., 2004. Managing cross-cultural issues inglobal software outsourcing. Commun. ACM 47 (4), 62–66.

Kwak, Y.H., Stoddard, J., 2004. Project risk management: lessons learned fromsoftware development environment. Technovation 24, 915–920.

Litwin, G.H., Stringer, R.A., 1968. Motivation and Organizational Climate.Harvard University Press, Boston, MA.

London, M., Smither, J., 2002. Can working with an executive coach improvemultisource feedback ratings over time? A quasi-experimental field study.Personnel Psychology 56, 23–46.

Luthans, F., Norman, S.M., Avolio, B.J., Avey, J.B., 2008. The mediating roleof psychological capital in the supportive organizational climate–employeeperformance relationship. Journal of Organizational Behavior 29, 219–238.

Lyytinen, K., Mathiassen, L., Ropponen, J., 1998. Attention shaping andsoftware risk—a categorical analysis of four classical risk managementapproaches. Information Systems Research 9 (3), 233–255.

Masri, M.E., Rivadry, S., 2010. Specifying the software project risk construct.Americas Conference on Information Systems (AMCIS) AMCIS 2010Proceedings Association for Information Systems. August 12–15.

Mathiassen, L., Seewaldt, T., Stage, J., 1995. Prototyping and specifying:principles and practices of a mixed approach. Scand. J. Inf. Syst. 7 (1), 55–72.

McConnell, S., 1996. Rapid Development. Microsoft Press, Redmond, WA.McLean, E.R., Smits, S.J., Tanner, J.R., 1996. The importance of salary on job

and career attitudes of information systems professionals. Information andmanagement 30, 291–299.

Morrison, E., 1993. Longitudinal study of the effects of information seeking onnewcomer socialization. Journal of Applied Psychology 78, 173–183.

Nah, F., Lau, J., Kuang, J., 2001. Critical factors for successful implementationof enterprise systems. Business Process Management Journal 7 (3),285–296.

Nasscom, 2009. Strategic Review — A Complete Report 2009.Neumann, D.E., 2002. An enhanced neural network technique for software risk

analysis. IEEE Trans. Softw. Eng. 28 (9), 904–912.Nicholson, B., Sahay, S., 2001. Some political and cultural issues in the

globalization of software development: case experience from Britain andIndia. Information and Organization 11, 25–43.

Nidomolu, S.R., Goodman, S.E., 1993. Computing in India: an Asian elephantlearning to dance. Commun. ACM 36 (4), 15–22.

Oz, E., Sosik, J., 2000. Why information systems projects are abandoned: aleadership and communication theory and exploratory study. Journal ofComputer Information Systems 66–78 Fall.

Oza, N., 2006. An empirical evaluation of client-vendor relationships in Indiansoftware outsourcing companies. PhD. Dissertation.

Pan, J., 1999. “Software Reliability”, CarnegieMellonUniversity. http://www.ece.cmu.edu/~koopman/des_s99/sw_reliability. assessed on 24th August 2010.

Paul, A.K., Anantharaman, R.N., 2004. Influence of HRM practices onorganizational commitment: a study among software professionals in India.Human resources development quarterly vol. 15 (1), 77–88 Spring 2004.

Procaccino, J.D., 2006. Quantitative Models for Early Prediction of SoftwareDevelopment Success: A Practitioner's Perspective. Ph.D Dissertation.

Procaccino, D.J., Verner, S.O., Marvin, D., 2002. Case study: factors for earlyprediction of software development success. Journal of Information &Software Technology 44, 53–62.

Rainer, A., Hall, T., 2004. Identifying the causes of poor progress in softwareprojects metrics. 10th IEEE International Symposium on Software Metrics(METRICS'04), pp. 184–195.

Rasch, R.H., Henry, L.T., 1992. Factors affecting software developers'performance: an integrated approach. MIS Q. 16 (3), 395–413.

Renn, R., 2003. Moderation by goal commitment of the feedback-performancerelationship: theoretical explanation and preliminary study. HumanResource Management Review 13, 561–580.

Ropponen, J., Lyytinen, K., 2000. Components of software development risk:what influences it—a project manager survey. IEEE Trans. Softw. Eng. 26(2), 98–112.

Rubin, A., Babbie, E., 2002. Research Methods for Social Work. Brooks/ColePublishing Company, Pacific Grove, Carlifornia.

Sabherwal, R., Sein, M., Marakas, G., 2003. Escalating commitment toinformation systems projects: findings from two simulated experiments.Information & Management 40 (8), 781–798.

Schmidt, R., Lyytinen, K., Keil, M., Cule, P., 2001. Identifying software projectrisks: an international Delphi study. Journal of Management InformationSystems 17 (4), 5–36.

Schneidewind, N., 2006. Software reliability engineering process. Innov. Syst.Softw. Eng. 2 (3–4), 179–190.

Shahzad, B., Safvi, S.A., 2010. Risk mitigation and management scheme basedon risk priority. Global journal of computer science and technology 10 (4),108–113.

Smite, D., 2006. Requirements management in distributed projects. Journal ofUniversal Knowledge Management 1 (2), 69–76.

Smith, D., Eastcroft, M., Mahmood, N., Rode, H., 2006. Risk factors affectingsoftware projects in South Africa. South African Journal of BusinessManagement 37 (2), 55–65.

Snow, A.P., Keil, M., Wallace, L., 2007. The effects of optimistic andpessimistic biasing on software project status reporting. Information andManagement 44 (2), 130–141.

Tafti, M., 2005. Risks factors associated with offshore IT outsourcing. IndustrialManagement and Data Systems 105 (5), 549–560.

Verner, J.M., Evanco, W.M., Cerpa, N., 2007. State of the practice: anexploratory analysis of schedule estimation and software project successprediction. Information and Software Technology 49 (2), 181–193.

Verner, J.M., Beecham, S., Cerpa, N., 2010. Stakeholder Dissonance:disagreements on project outcome and its impact on team motivation acrossthree countries. SIGMIS-CPR'10, May 20–22, 2010, Vancouver, BC,Canada, pp. 25–33.

Wallace, L., Keil, M., Rai, A., 2004. How software project risk affects projectperformance: an investigation of the dimensions of risk and an exploratorymodel. Decis. Sci. 35 (2), 289–321.

Warkentin, M., Moore, R.S., Bekkering, E., Johnston, A.C., 2009. Analysis ofsystems development project risks: an integrative framework. The DATABASE for advances in Information Systems 40 (2), 8–26.

Whitmaker, B., McKinney, J., 2009. Role clarity, social skills and the feedbackseeking job satisfaction link. International Journal of OrganizationalBehavior 14 (1), 54–68.

Woodruff, C.K., 1990. Managing the results: an examination of professionalgroup perceptions of organizational practice. Information and Management19, 135–147.

Xu, X.X., He, J., 2008. Impact of team attitude and behaviour on is projectsuccess. Communications of the IIMA 8 (4), 41–52.

Yen, H.R., Li, E.Y., Niehoff, B.P., 2008. Do organizational citizenshipbehaviors lead to information system success? Testing the mediation effectsof integration climate and project management. Information and Manage-ment 45 (6), 394–402.

Zhou, L., Vasconcelos, A., Nunes, M., 2008. Supporting decision making in riskmanagement through an evidence-based information systems project riskchecklist. Information Management and Computer Security 16 (2),166–186.