Exploring risk dimensions in the Indian software industry

PA

PE

RS

78 September 2011 � Project Management Journal � DOI: 10.1002/pmj

INTRODUCTION �

The Indian software industry is characterized by the diversity of theprojects it engenders. From size to complexity and from scope to crit-icality, the attributes of a software project can be varied. Some projectsare big, encompassing numerous resources with complex integration

and interorganizational developmental processes, whereas others are rela-tively small and simple. Some have a worldwide reach, whereas some mayaffect only a small division or client group (Keil, Tiwana, & Bush, 2002). Somesoftware projects are developed “in-house,” whereas others may be out-sourced. Regardless of the size, complexity, criticality, or scope, the successof software projects is not guaranteed. There is strong evidence to suggest anunacceptably high rate of software project failure in the software industry. Alarge number of projects are abandoned before completion or are complet-ed after comprising on quality, cost, budget, or all three (Standish Group,2009).

There has been a wide range of studies conducted, which have addressedissues pertaining to software projects: their success, their failure, the effi-ciency of the team handling them, and the organizational climate in whichthey are developed. Various studies (Anudhe & Mathew, 2009; Bannerman,2008; Boehm, 1989; Costa, Barros, & Travassos, 2007; Dash & Dash, 2010;Dey, Kinch, & Ogunlana, 2007; Keil, Smith, Pawlowski, & Jin, 2004; Oz &Sosik, 2000; Ropponen & Lyytinen, 2000) have been conducted in the past tounveil the reasons for the high rates of delays and failures in the softwareindustry. Miscommunication of requirements, inaccurate estimations, lowteam member morale, lack of client ownership, and lack of top managementsupport are some of the risk factors that have been mentioned by most of theresearchers, thus emphasizing the technical, managerial, and peopleaspects. Nonetheless, it cannot be said with the utmost confidence as towhat extent and magnitude these factors affect the success or failure of thesoftware project, nor can it be stated how many of these factors genuinelyaffect the success or failure of the software project. The reason for this vague-ness is simple: these factors are merely products of the wide variety of perceptions of the software practitioners who actually handle these factorsduring the software development life cycle. A different hierarchical level willproduce a different perception; a different span of experience will lead to adifferent perception; and a different project attribute will create a differentperception. Thus, it is a fact that the perception toward these factors varieswidely in the experience and designation of the software practitioners, aswell as the duration, team size, and value of the project. The question now is:

Exploring Risk Dimensions in theIndian Software IndustryArpita Sharma, Professional Development Department, Jaypee Institute of InformationTechnology, Noida, IndiaSantoshi Sengupta, Professional Development Department, Jaypee Institute of InformationTechnology, Noida, IndiaAayushi Gupta, Professional Development Department, Jaypee Institute of InformationTechnology, Noida, India

ABSTRACT �

The success of software projects is quite sub-jective in nature and is fettered by many risks,the perception of which varies from individual toindividual and largely depends on the demo-graphic characteristics of the executives andeven the characteristics of the project. Thisstudy aims to identify and gauge the softwarerisk dimensions and analyze the differences ofperception among executives toward softwarerisks. The contributions of this study untanglethe issues underlying risks in the softwareindustry and associates these issues with theperception of the “human” factor present in the industry.

KEYWORDS: software projects; risks;demographics

Project Management Journal, Vol. 42, No. 5, 78–91

© 2011 by the Project Management Institute

Published online in Wiley Online Library

(wileyonlinelibrary.com). DOI: 10.1002/pmj.20258

September 2011 � Project Management Journal � DOI: 10.1002/pmj 79

How does the perception toward thesefactors vary with various groups of thedemographic and project attributes?

This study aims to evaluate the var-ious risk dimensions across a numberof demographic characteristics of soft-ware practitioners and also aims tostudy the variance in risk dimensionsamong the various project characteris-tics handled by software practitioners.This study is important because it helpsus understand the perception of theteam vis-à-vis middle managementand top management.

Literature ReviewSoftware Risk DimensionsNumerous studies have been conductedon the identification and managementof software risk factors. These studiesdate back to 1975, when Brooks cited thecauses of project failure on the basis ofhis experience at IBM. Thereafter, manyresearchers (Anudhe & Mathew, 2009;Bannerman, 2008; Boehm, 1989; Costaet al., 2007; Dash & Dash, 2010; Dey et al., 2007; Keil et al.; 2004; Oz & Sosik,2000; Ropponen & Lyytinen, 2000) havebeen working incessantly on the identi-fication and management of softwarerisks, some of which are discussed in thisstudy. Dey et al. (2007), through a casestudy on The Town and CountryPlanning Office (TCPO) in Barbados,identified the unavailability of key per-sonnel, employee turnover, and incor-rect/incomplete requirement as therisks affecting software development.The study also developed an integratedframework for managing risk in soft-ware development with the involve-ment of the stakeholders in the TCPO.Verner, Evanco, and Cerpa (2007) con-ducted exploratory statistical analyseson both the software developers and topmanagement to identify their percep-tions about the determinants of projectsuccess and used logistical regression topredict project success. Accordingly, thedevelopers’ perspectives suggest thatsuccess is more likely to happen if theproject manager is involved in schedulenegotiations; adequate requirements

information is available when the esti-mates are made; initial effort estimatesare good; staff leave is taken intoaccount; and more staff is not addedlate in the project in order to meet anaggressive schedule.

Zhou, Vasconcelos, and Nunes(2008) analyzed ten case studies in theUnited Kingdom, the United States, andNew Zealand to identify critical risk fac-tors (scope creep, unwillingness of thecustomer to accept final systems, poorproject management, etc.) at the pre-implementation and implementationstages of the software project.Bannerman (2008) conducted a study ingovernment agencies in Australia toinvestigate the practices of a state gov-ernment when dealing with softwareprojects. Analysis of the study uncoveredten categories of risk factors—namely,project governance, project setup, partner engagement, business propri-etorship, project management, changemanagement, management of projects,recognition of red flags, management ofrisk, and benefit realization. The studyalso suggested the various risk manage-ment techniques used in these projects.Iacovou and Nakatsu (2008) used theDelhi survey method on 57 senior ITprofessionals and identified lack of topmanagement commitment, the originalset of requirements miscommunicated,language barrier in project communica-tions, lack of required technical know-how by the offshore team, and failure toconsider all costs as the core risk factors.The study aimed at providing insightinto the risks affecting offshore-outsourced development projects.Anudhe and Mathew (2009), using case-based methodology and structured andsemistructured interviews with seniormanagement of various Indian softwarecompanies, described various risk fac-tors affecting the software projects.Schedule and budget management(developing a collaborative work culturewith clients), client expectations (edu-cating the client to involve a deep level ofinvolvement with the customer),requirements capture (elaborate data

collection and proactive analysis),staffing (maintaining buffer resources,involving the client in resource recruit-ment), and changes in the client’s corpo-rate structure (transparency and adequatecommunication) are some of the riskfactors, and their mitigation is men-tioned in their study.

Perspectives of Software ProfessionalsThe concept that different stakeholderscan perceive software projects in differ-ent ways has also been well establishedin the literature (Lyytinen, Mathiassen,& Ropponen, 1998). Keil et al. (2002)have demonstrated that users and proj-ect managers differ in terms of theirproject risk perceptions, whileWarkentin, Bekkering, and Moore(2007); Warkentin, Bekkering, Johnston,and Moore (2009); and Stephen, Keil,Mathiassen, Shen, and Tiwana (2007)have exhaustively studied the percep-tion of risk among various demographiccharacteristics of software professionalsand have suggested that professionalswith more experience in project leader-ship are more likely to view projects andtheir associated risks more holisticallyand assign and resolve risk as if theywere organizational in nature. Agarwaland Rathod (2006), Linberg (1999),Wateridge (1995), Verner et al. (2007),and Verner, Beecham, and Cerpa (2010)have explored the success indicators asperceived by software professionals.

All of these studies provide greatinsight into the practitioner’s perceptionabout the software risks dimensions;however, a study about the perceptionamong various demographic character-istics of software practitioners on thesedimensions is largely anecdotal andlacking in the Indian context. Further-more, not much research has beendone in understanding the dynamics of risk among various project charac-teristics handled by the software practi-tioners.

Objectives of the StudyBased on the literature review and thegaps identified in it, the objectives ofthe study are as follows:


Exploring Risk Dimensions in the Indian Software IndustryP

AP

ER

S

1. To identify and rank the software riskdimensions affecting software proj-ects in India.

2. To evaluate the difference of percep-tion toward risk dimensions on thebasis of the designation and experi-ence of software professionals.

3. To evaluate the difference of percep-tion toward risk dimensions on thebasis of project characteristics—namely, team size, duration, andtotal value of the project handled byIndian software professionals.

Research MethodologyA systematic and coherent approachwas adopted for the research study.First and foremost, a pilot study wasdone on 40 software project managersworking in software companies locatedin the National Capital Region (India)to gauge the risk factors that affectedthe success of their last executed proj-ects. The project managers in the pilotstudy were specifically asked to identifythe critical risk factors affecting thesoftware development life cycle. Basedon the perceptions of the project man-agers in the pilot study and in-depthsecondary data analysis, an exhaustivelist of 23 risk items affecting the soft-ware development life cycle was identi-fied. These items were meticulouslydrawn out after thorough interviewsand a comprehensive literature review;thus, the list is all-inclusive. A question-naire was prepared using these riskitems and was administered to softwareprofessionals with a minimum of fouryears’ experience in handling softwareprojects in India.

To carry out extensive research, asurvey design was used. Four major IThubs in India—namely, NCR (Gurgaon,Noida, Delhi, Faridabad), Hyderabad,Bangalore, and Chennai—were select-ed. From each IT hub, eight companieswere randomly selected, thus bringingthe total to 32 companies. A total of 900questionnaires were sent out, of which340 filled-in questionnaires werereturned, with a response rate of 37.7percent; of these, only 300 were found

to be completely filled out and 40 werediscarded. A random sampling tech-nique was used to gather data from ITprofessionals with more than four yearsof experience in handling software proj-ects. The questionnaire was intricatelydesigned to elicit information about (1) the personal characteristics of therespondents (namely, designation andtotal experience); (2) project character-istics handled by the respondents(namely, team size, duration of the proj-ect, and total value of the project); and(3) the risk factors impacting the success of the last executed project. Inaddition to gathering data through thequestionnaires, in-person interviewswere also conducted with the projectmanagers and senior management toaccentuate the data collected. StatisticalPackage for the Social Sciences (SPSS)version 17.0 was consistently used forthe statistical analyses.

Analysis and FindingsThe analysis of the data set obtainedwas conducted in several steps. First,the major software risk dimensionswere identified using principal compo-nent analysis (PCA). PCA is widely usedto examine the underlying patterns fora large number of variables and todetermine if the information can besummarized in a small set of factors orcomponents for subsequent correlationor regression. Second, ANOVA-Duncanpost-hoc was conducted to test thevariance in these dimensions amongvarious demographics and projectcharacteristics. The reliability of thesurvey instrument was also tested.

To test the validity of the instrument,Cronbach’s alpha and Kaiser-Meyer-Olkin (KMO) tests were conducted.Cronbach’s alpha was calculated tomeasure the internal consistency andreliability of the instrument. The resultsof the Cronbach’s alpha, Bartlett’s testof sphericity, and KMO tests are shownin Table 1.

Personal Profiles of the RespondentsThe first section of the instrumentgathered information about the per-sonal profiles of the respondents,which included designation and totalexperience; each of these backgroundvariables is described in the sectionsthat follow. It must be noted here thatthe open-ended questions were askedfrom the respondents regarding thedemographic and project characteris-tics. Because these data could not beused in raw form, the data were tabulat-ed and grouped together according tothe cumulative frequencies in such away that each group has almost equaldistribution. Table 2 provides thedemographic characteristics.

DesignationBecause the questionnaire was deliber-ately administered to IT professionalswith more than four years of experiencehandling software projects, the respon-dents were primarily project leads andhigher-level employees. As shown inTable 2, out of 300 respondents, 141 (47percent) were primarily project man-agers, senior managers, and accountmanagers, who were specified as Level2, whereas 43 respondents (14 percent)

Kaiser-Meyer-OlkinNumber Cronbach’s Measure of Bartlett’s Test of of Items Alpha Sampling Adequacy Sphericity

Software 23 0.956 0.916 Approx. 5,309.252risks Chi-Square

df 253.00

Sig. 0.000

Table 1: Reliability and validity of the software risk factors and organizational climate factors.


were from the top management team(chief operating officer, head of IT,director, chief executive officer), whowere specified as Level 3. Such a widescale of distribution was necessary toenable a better analysis and interpreta-tion of the data.

Total ExperienceAs shown in Table 2, the respondentswere classified into three categories,depending on their total experience.The second category (123 respondents[41 percent]) was dominated by projectmanagers and senior project man-agers, with total experience rangingfrom 10 to 14 years. A few directors andvice presidents were also in this cate-gory. In the last category, with morethan 14 years of experience, there were65 (21.7 percent) respondents, mainlyfrom the senior management team. Afew senior managers and accountmanagers fell under this category. Themain reason for this blend is that thesoftware industry is a modern industry,and consists of 25- to 30-year-old indi-viduals who can start their own busi-nesses and hire their own employees;therefore, it is easier to reach higherlevels at an early age compared withthe traditional industries (e.g., iron andsteel).

Thus, as seen from the demograph-ics, the sample was dominated by project managers and senior projectmanagers. Furthermore, an in-depthanalysis has been conducted to gaugethe profiles of projects handled by therespondents.

Profile of the Last Executed ProjectHandled by the RespondentsThe respondents were asked to providedetails of the last executed project theyhandled. The instrument containedquestions on the team size of the proj-ect, total duration of the project, and,

finally, the approximate value of theproject in US dollars. These details areprovided in Table 3.

Team SizeThe total team size was divided intothree categories. As is clear from Table3, 100 projects were handled by a teamsize of three to ten members, whereas89 projects were handled by a teamsize of 11 to 20 members; thus, 189 (63percent) projects handled by therespondents had a team of 20 mem-bers or less. On the higher side, only 25projects (8.4 percent) had a team rang-ing from 50 to almost 500. Only oneproject had a total value of US $145million, with a team size of 500 teammembers.

DurationAs shown in Table 3, it was found that113 projects (37.7 percent) were com-pleted in less than one year. Afterdetailed conversations with several ITprofessionals, it was found that proj-ects cannot really be classified asshort-term, medium-term, or long-term projects because they are organi-zation-specific. For companies withthousands of employees, a project witha one-year duration would be consid-ered a short-term project, but for acompany with only 10 employees, thesame project would be considered along-term project.

Characteristics Number Percentage

Designation 116 38.70%Level 1(project leads, technical leads, consultants, senior software engineers, lead consultants)

Level 2 141 47%(project managers, senior managers, account managers)

Level 3 43 14.30%(chief operating officer, head of IT, director,chief executive officer)

Total experience (in years)4–9 years 112 37.30%10–14 years 123 41%More than 14 years 65 21.70%

Table 2: Demographic characteristics of the respondents.

Project Details Number Percentage

Number of team members in the project3–10 100 33.30%11–20 89 29.70%More than 20 111 37%

Time taken to complete the project (in months)1–9 months 113 37.70%10–19 months 96 32%More than 20 months 111 37%

Total value of the project (in million dollars)0.02–0.70 102 34%0.71–2.00 89 29.70%Greater than 2.00 109 36.30%

Table 3: Characteristics of the projects handled by the respondents.



AP

ER

S

ValueAs shown in Table 3, the projects werealmost evenly distributed among thethree groups, with most of the projectsfalling into either the first group of proj-ect value (up to US $70,000) or the thirdgroup (value above US $2 million).However, after a detailed analysis, itwas found that most of the projectsoutsourced to Indian software compa-nies ranged between US $1 and 10 mil-lion, with 151 projects (50.3%) fallinginto this category.

Thus, it can be seen from the profileof the project that the sample is ahomogenous mix of team, time, andtotal value of the project. Further studywas done on extracting the risk factorsas rated by these respondents.

Identification of the RiskDimensionsAs already pointed out, the 23 risk itemsused for the study were identified afteran all-encompassing and exhaustivesecondary data analysis and pilot study.Table 4 describes the 23 risk items usedfor the study.

Factor analysis was done to extractthe software risk factors affecting thesuccess of the projects; principal com-ponent analysis was the method ofextraction and Varimax was the rotationmethod. As per the Kaiser criterion,only factors with eigenvalues greaterthan 1 were retained. Four factors in theinitial solution have eigenvalues greaterthan 1; together, they account foralmost 68% of the variability in the orig-inal variables. The items falling undereach of these factors were then dealtwith quite prudently. The factorsextracted for the study are shown inTable 5.

SRS Variability RiskThe software requirement specification(SRS) variability risk is the name givento the first risk dimension identifiedthrough factor analysis. The itemsincluded in this are shown in Table 5.All of these items have one commonal-ity: lack of proper flow of informationleading to requirement variability. The

problem of requirement variability ini-tiates at the stage in which the projectmanager does not have any prior expe-rience in handling the similar type ofproject. This problem is further height-ened when the manager fails to under-stand the client because of regional orlanguage differences. Together, thesetwo issues create a ripple effect andopen up the sea of miscommunicationof requirements, gross estimation errors,conflicting and continuous requirementchanges, and inaccurate require-ment analysis, thus delaying therecruitment of the team, which resultsin a gross miscalculation of the cost ofthe project. This is the initiating stage of the project, and such issues arebound to create many problems in theproject, even resulting in cancellation.The same has been reiterated by Boehm(1991), Baccarini (1996), King (1994),Clancy (1995), and Smite (2006).Besides this, the lack of client owner-ship and lack of drive to specify require-ments are major contributors to vaguerequirements, and not enough clarifi-cation is done to solve them in time.Researchers even state that projectmanagers fail to make correct estima-tions in the initial stages of the softwaredevelopment and sometimes distortthe facts or become too optimistic, thuscreating gross estimation errors (Keil,Im, & Mahring, 2007; Snow, Keil, &Wallace, 2007). Thus, it is obvious howcrucial it is to understand the require-ments correctly for the success of theproject.

Team Composition RiskAs is clear from Table 5, the second fac-tor has seven items loaded on it, and allare related to team composition risk.This factor deals with the risks relatedto the team members responsible forthe development and execution of theproject. The major contributors to theserisks are the lack of top managementsupport and unavailability of a compe-tent project manager in handling theteam. Any lack of interest exhibited bytop management will result in hiring of

an inexperienced or highly diverseteam. In addition, if top management isnot keen on investing in training or hir-ing a subject matter expert, there willbe a risk of unavailability of a domainexpert, which will create problems forthe project (Barki & Hartwick, 1989;Gioia, 1996; Keil et al., 1998; Leitheiser& Wetherbe, 1986; Nah et al., 2001). Inaddition to senior management’s lackof interest, the project manager is alsoresponsible for contributing to theteam’s composition risk. The projectmanager acts as a liaison between topmanagement and the team. All issuesrelated to promotion and performanceappraisals are handled by the projectmanager. If the manager is inept athandling the team issues, there isbound to be dissatisfaction amongteam members, resulting in low morale,lack of commitment, and, ultimately,high turnover (Bosco, 2004; Dey et al.,2007; Faraj & Sambamurthy, 2006;Standish Group, 2009). This is a veryimportant risk affecting the project.

Control Processes RiskAs is clear from Table 5, controlprocesses risk arises when the projectdoes not have a good and sound config-uration management. Configurationmanagement is the detailed recordingand updating of information thatdescribes the project’s hardware andsoftware. Such information typicallyincludes the versions and updates thathave been applied to the software prod-uct and the locations and networkaddresses of hardware devices (Babich,1986; Bersoff, 1984). If the project doesnot have a good and systematic config-uration plan, it will lead to poor docu-mentation, because the version will notbe saved, updated, or made availablewhen needed. The problem will be fur-ther aggravated due to insufficient test-ing. When a team member makeschanges in the code and fails to save itin the central repository, it results in aloss to the project. The reason for this isvery simple, because when the changesare not communicated to the tester,


they will not be able to test the code,thus resulting in insufficient testing. Apoor and mediocre code with inade-quate maintenance procedures is alsocaused by improper configuration con-trol. The importance of configurationcontrol and documentation has alsobeen mentioned by Huang and Trauth

(2007); Oza, Hall, Rainer, and Grey(2004); Sabherwal, Sein, and Marakas(2003); and Jannson (2007).

Dependability RiskDependability risk is the name given tothe fourth and last factor; the itemsfalling under this risk are shown in

Table 5. It is extremely vital for a soft-ware project to be dependable and reli-able. Software dependability is definedas the ability to avoid service failuresthat are more frequent and more severethan acceptable (Avizienis, Laprie,Randell, & Landwehr, 2004). Dependa-bility is a broad term, which includes

23 Risk Items Prior Literature and Pilot Study

Working with inexperienced team Addison and Vallabh (2002); Hoodat and Rashidi (2009); Jiang and Klein(2001); Keil, Cule, Lyytinen, and Schmidt (1998); Schmidt, Lyytinen, Keil, andCule (2001); Reel (1999); Smith et al. (2006); pilot study

Delay in recruitment and resourcing Pilot study

Less or no experience in similar projects Keil et al. (1998); McFarlan (1982); McLeod and Smith (1996); pilot study

Insufficient testing Pilot study

Team diversity Pilot study

Lack of availability of domain expert Barki and Hartwick (1989); Gioia (1996); Keil et al. (1998); Leitheiser andWetherbe (1986); Nah, Lau, and Kuang (2001); pilot study

Lack of commitment from the project team Pilot study

High level of attrition Arora, Arunachalam, Asundi, and Fernandes (2001); Dey et al. (2007); Reel(1999); pilot study

Estimation errors Hoodat and Rashidi (2009); Smith et al. (2006); Zhou et al. (2008)

Inaccurate requirement analysis Addison and Vallabh (2002); Field (1997); Keil et al. (1998); Mursu, Soriyan,and Olufokunbi (1996); Schmidt et al. (2001); pilot study

Lack of top management support Barki and Hartwick (1989); Gioia (1996); Keil et al. (1998); Leitheiser andWetherbe (1986); Nah et al. (2001)

Low morale of the team Pilot study

Miscommunication of requirements Iacovou and Nakatsu (2008); Shull, Rus, and Basili (2000); Zhou et al. (2008)

Conflicting and continuous requirement changes Addison and Vallabh (2002); Boehm (1989); Clancy (1995); Hoodat and Rashidi(2009); Jones (1993); King (1994)

Language and regional differences with client Anudhe and Mathew (2009); Arora et al. (2001)

Lack of client ownership and responsibility Keil et al. (1998); Mursu et al. (1996)

Inadequate measurement tools for reliability Pan (1999)

Third-party dependencies Krasner (1998)

Inability to meet specifications Pilot study

Inaccurate cost measurement Galorath and Evans (2006); Masticola (2007)

Poor code and maintenance procedures Pilot study

Poor documentation de Souza, Anquetil, and de Oliveira (2007); Huang and Trauth (2007); Mattsson(2008); Oza et al. (2004)

Poor configuration control Aharon and Ilana (2010); Sabherwal, Sein, and Marakas (2003)

Table 4: Risk items used for the study.



AP

ER

S

availability, reliability, safety, integrity,and maintainability of the software(Avizienis et al., 2004). Dependability ofthe software is therefore very crucial forthe success of a project. For the suc-cessful completion of a project, allcomponents (hardware and software)must be available at the right time andin the right place. To make things easi-er, sometimes part of the project is out-sourced to a third-party vendor, whichcan be a great advantage if the rightvendor is chosen. On the other hand, if

an unreliable vendor is chosen, therecan be many problems, such as poorand undependable components, latedelivery of critical components, and soforth. This will create a disastrous effecton the project and prevent the projectteam from meeting the customer orclient’s specifications. Furthermore,any component from the third-partyvendor cannot really be tested in isolation and, if proved unreliable, cancompletely thwart the entire project. This finding about dependability and

reliability is supported by numerousstudies and also conforms to studies bySherer (1995), Pan (1999), Krasner (1998),and Ropponen and Lyytinen (2000).

Ranking of Software Risk DimensionsFor determining the most importantrisk affecting the software projects inIndia, means and standard deviationsof the risk dimensions were calculated.The respondents were asked to rate theeffect of each risk based on the success oftheir last executed project, on a scale of 1 to 5, in which 5 was too much effectand 1 was no effect at all. After the fac-tor analysis, when four factorsemerged, the score of each of the fac-tors was computed by taking out themean of the items falling under eachfactor. For example, in order to calcu-late the mean of dependability, thescores of all the items (i.e., third-partydependencies, inability to meet specifi-cations, and inadequate measurementtools for reliability) were first added,and then the mean was calculated.Similarly, means and standard devia-tions were calculated for all the factors.The ranking of the dimensions, basedon the means and standard deviations,is shown in Table 6.

It is clear from Table 6 that SRS vari-ability has the highest mean of 3.06,stating that most of the respondentsconsider software requirement specifi-cation variability as the most importantrisk affecting software projects. Thestandard deviation for SRS variabilityrisk is 1.06. The SRS variability risk isclosely followed by dependability risk,with a mean of 2.84; team compositionrisk, with a mean of 2.75; and, finally,control processes risk, with a mean of2.52, thus, clearly proving that SRS vari-ability risk is the most important riskaffecting Indian software projects,which is also in line with the findings ofSharma, Gupta, and Khilnani (2009).Although SRS variability risk is per-ceived to be the most crucial risk, is the perception the same across all thegroups of designation and experience?This is explored in the following section.

FactorFactor Item Loading Factor Name

1 Conflicting and continuous requirement changes 0.789 SRS

Inaccurate requirement analysis 0.786Variability

Miscommunication of requirements 0.765Risk

Estimation errors 0.687

Less or no experience in similar projects 0.646

Inaccurate cost measurement 0.635

Language and regional differences with client 0.612

Delays in recruitment and resourcing 0.604

Lack of client ownership and responsibility 0.533

2 Lack of availability of domain expert 0.761 Team

Working with inexperienced team 0.651Composition

Team diversity 0.650Risk

Lack of commitment from the project team 0.628

Low morale of the team 0.613

High level of attrition 0.596

Lack of top management support 0.561

3 Poor documentation 0.733 Control

Poor code and maintenance procedures 0.716Processes

Insufficient testing 0.556Risk

Poor configuration control 0.529

4 Third-party dependencies 0.803 Dependability

Inability to meet specifications 0.598Risk

Inadequate measurement tools for reliability 0.578

Table 5: Factor analysis of the risk dimensions.


Comparison of Risk FactorsAcross Various Personal andProject CharacteristicsThe dimensions of software risk so for-mulated after the factor analysis werethen compared with the various per-sonal characteristics of the respondentsand the project characteristics handledby the respondents chosen for thestudy. The personal characteristicsincluded experience and designation,whereas project characteristics includ-ed total team size, total time taken tocomplete the project, and the totalvalue of the project. The comparisonsare discussed in the following section.

DesignationDuncan’s Mean Test was applied tocompare the dimensions of softwarerisk among the three designationgroups of the respondents. All riskdimensions—namely, SRS variability,team composition, control processes,and dependability—showed significantdifferences in mean and standard devi-ation values. Table 7 shows all the values

of mean and standard deviations of the dimensions of software risk across thevarious designation groups.

As shown in Table 7, the F-value ishighest in cases of SRS variability. Thisfactor has been ranked the highest byrespondents of level 1 (project leads,technical leads, consultants, and ana-lysts), with a mean of 3.58 and a stan-dard deviation of 0.87, which impliesthat level 1 respondents perceive theserisks as having a high effect on the suc-cess of the project. Dependability andteam composition risks, with means of3.26 and 3.19, respectively, are againconsidered more significant risks bylevel 1 respondents than the other twogroups, which are dominated by projectmanagers (level 2) and directors (level3). This is due to the lack of sufficientexperience, expertise, and authority inhandling and mitigating risks. Anotherinteresting fact that emerged out of theanalysis was that the difference was sig-nificant only with level 1. It should benoted here that there were no signifi-cant differences between level 2 and

level 3 respondents, thus testifying thatthese two levels have an almost similaropinion. When compared with level 1employees, both these groups showedsignificant difference. Hence, it can besaid with statistical confidence thatthere exists a difference in perceptionof these risks among the various desig-nation groups, which conforms tomany other previous studies. Stephenet al. (2007) testified that IT projectmanagers with more experience haverisk perceptions that differ from thoseof more junior managers. Warkentin et al. (2009) has also concluded that,instead of viewing risks as separate ordiscrete categories, managers at higherlevels, owing to their more comprehen-sive organizational perspectives, aremore likely to consider risks essentiallyorganizational in nature comparedwith their junior managers. The samehas been reiterated by Smith, Eastcroft,Mahmood, and Rode (2006).

Total ExperienceDuncan’s Mean Test was applied tocompare the dimensions of softwarerisk among three groups and formed onthe basis of total experience. Significantdifferences were found in the mean val-ues of all of the dimensions of risk.Table 8 shows all the values of meanand standard deviations of the dimen-sions of risk across the various experi-ence groups. As shown, the F-value washighest in the case of SRS variability,followed by team composition, controlprocesses, and dependability. It should

S. No. Factor Name Mean Standard Deviation

1 SRS Variability Risk 3.06 1.06

2 Dependability Risk 2.84 1.13

3 Team Composition Risk 2.75 1.03

4 Control Processes Risk 2.52 1.05

Table 6: Means and standard deviations of the risk factors.

D1 (N � 116) D2 (N � 141) D3 (N � 43)Risk Factors Mean SD Mean SD Mean SD D1 v/s D2 D1 v/s D3 D2 v/s D3 F-value

SRS Variability 3.58 0.87 2.72 1.04 2.74 1.01 * * – 27.05**

Team Composition 3.19 0.98 2.41 0.94 2.67 1.05 * * – 20.89**

Control Processes 2.97 0.95 2.19 0.98 2.32 1.12 * * – 20.47**

Dependability 3.26 1.18 2.62 1.08 2.42 0.82 * * – 14.60**

Note. D1 � level 1, D2 � level 2, D3 � level 3; Duncan’s Mean Test.*Significant at 0.05 level. ** Significant at 0.01 level.

Table 7: Comparisons of risk factors among three designation groups.



AP

ER

S

be noted again that the difference wassignificant only between two groups(i.e., between E1 [up to 9 years of expe-rience] and E2 [10 to 14 years of experi-ence] and E1 and E3 [more than 14years of experience]). E2 and E3 had nosignificant differences between them asfar as the perceptions of these four riskfactors were concerned.

All four risks were ranked highest byE1 respondents, followed by E2, andthen E3. This is not surprising, becauseemployees with less experience are notas well versed in managing such issuesor even mitigating them, comparedwith veterans in the industry for whomsuch issues do not emerge as risks butas minor challenges that need to befaced and dealt with. Respondents inthe E2 and E3 categories, therefore,have similar opinions about such risks,and so there is no significant differencebetween the two. This finding also hascongruence with earlier studies, suchas those by Bourne and Walker (2004),Smith et al. (2006), and Warkentin et al.(2009), in which it was concluded thatemployees with more experience inproject leadership were more likely toview projects and their associated risksmore holistically and assign and resolverisks as if they were organizational innature.

Project CharacteristicsAfter comparing the dimensions ofsoftware risks with the various personalcharacteristics, the same dimensions

were compared with the various projectcharacteristics. The project characteristicsincluded total team size, total time takento complete the project, and the totalvalue of the project. The comparisonsare discussed in the sections that follow.

Total Team SizeSize refers to the magnitude of theresources needed to complete the proj-ect (Thompson, Iacovou, & Smith, 2009).According to this definition, humanresources engaged in a project make upthe team size. Past research also illus-trates that the level of resources correlateswith the complexity of the development(i.e., project-related risks [Baccarini,1996; Francalanci, 2001; Otto & Magee,2006]). The team size of the projects isan important variable and is associatedwith the risk dimensions. In this study,team size has been divided into threecategories—namely, T1 (up to 10 mem-bers), T2 (11 to 20 members), and T3(more than 20 members). As shown inTable 9, Duncan’s Mean Test was con-ducted to find the significant differ-ences among the means of these threecategories. The finding shows that noneof the F-values was significant; thus, itcannot be said with statistical confi-dence that the risk dimensions varywith the team size.

Total DurationThe total time taken for the completionof a project is an important attributeand is associated with risks, because it

is an extensive resource for any project(Warkentin et al., 2009). The total dura-tion of a project was categorized underthree heads—namely, TT1 (up to 9months), TT2 (10 to 19 months), andTT3 (more than 19 months). The riskfactors were, thus, compared with thesethree categories using Duncan’s MeanTest. Only team composition had sig-nificant differences among the threecategories, with an F-value of 3.1201(Table 10). None of the other risks hadany significant differences among thethree groups.

Team composition had a significantdifference only between the TT2 andTT3 categories (i.e., between projectswith durations of 10 to 19 months andprojects with durations of more than 19months). Duncan’s Mean Test showsthat there is a difference in mean valuesof risk between these two categories.Projects with longer durations have ahigher mean compared with projectswith shorter durations and this isbecause, as the length of time increas-es, the levels of employee morale andmotivation tend to diminish, becausesuch projects are generally viewed assoftware maintenance projects. Withlow or almost no challenge in the typeof work, along with high attrition,employees lack the commitment nec-essary for the project, and thus theteam composition emerges as a signifi-cant risk for projects with longer dura-tions (Morris, 2004; Schmidt et al.,2001). Ropponen and Lyytinen (2000)

E1 (N � 112) E2 (N � 123) E3 (N � 65)

Risk Factors Mean SD Mean SD Mean SD E1 v/s E2 E1 v/s E3 E2 v/s E3 F-value

SRS Variability 3.51 0.93 2.82 1.07 2.74 1.01 * * – 18.17**

Team Composition 3.14 0.99 2.52 0.97 2.51 1.02 * * – 13.61**

Control Processes 2.91 1.02 2.31 0.89 2.23 1.09 * * – 13.91**

Dependability 3.19 1.17 2.74 1.09 2.44 0.98 * * – 10.42**

Note. E1 � up to 9 years, E2 � 10–14, E3 � more than 14; Duncan’s Mean Test.*Significant at 0.05 level. ** Significant at 0.01 level.

Table 8: Comparisons of risk factors among three experience groups.


and Warkentin et al. (2009) have point-ed out that considering the time issueof a project, the team relationshipshave to be managed. As quoted inWarkentin et al. (2009), “Ultimately youneed effective communication chan-nels with your vendors and technologypartners. Mutual respect and under-standing play a large role in the rela-tionship” (p. 14). This clearly statesthat team composition is associatedwith the duration of a project and that ithas a larger impact on projects withlonger durations as compared with short-er ones.

Total Monetary ValueMoney is a critical resource that shouldbe allocated and monitored for the suc-cess of software and information sys-tems development projects (Laudise &Nuara, 2002; Warkentin et al., 2009).The total dollar value thus becomes animportant attribute for any project, and

it has been selected for comparing therisk factors. The total dollar values ofprojects in which the respondents wereinvolved are divided into three cate-gories—namely, V1 (up to US $0.70 mil-lion), V2 (US $0.71–2.00 million), and V3(more than $2.00 million). As shown inTable 11, Duncan’s Mean Test wasapplied to see if there were any differ-ences in the mean values of the risk fac-tors among the three categories of dollar values associated with the lastexecuted projects; it was determinedthat none of the differences was signifi-cant. Thus, it cannot be said with statis-tical confidence that there exists a difference in the mean value of the riskfactors across the three categories ofproject value.

Thus, it is clear how each of the soft-ware risk dimensions is viewed by thevarious stakeholders within the soft-ware development organization. Ratherthan viewing many software risks as

separate or discrete categories, seniorproject managers, with their morecomprehensive organizational per-spectives, view all risks as essentiallyorganizational in nature, comparedwith the perspectives of the projectleads and technical leads. As far as thevariance in risk dimensions among theproject characteristics is concerned,the analysis did not show significantvariance among most of the projectcharacteristics. The team compositionrisk, however, did show a significantvariance among the large-size projects,which is also in line with the findings ofRopponen and Lyytinen (2000).

Conclusion, Limitations, andImplicationsTo conclude, it can be said that based onthe perceptions of software executives—ranging from middle to top level—primarily four kinds of risk dimensionsprevail in the Indian software industry

T1 (N � 100) T2 (N � 89) T3 (N � 111)

Risk Factors Mean SD Mean SD Mean SD T1 v/s T2 T1 v/s T3 T2 v/s T3 F-value

SRS Variability 2.99 1.11 3.11 1.03 3.08 1.03 – – – 0.3304

Team Composition 2.71 1.13 2.74 1.01 2.79 0.96 – – – 0.1772

Control Processes 2.64 1.13 2.43 0.84 2.47 1.13 – – – 1.1641

Dependability 2.77 1.22 2.89 1.06 2.85 1.10 – – – 0.2921

Note. T1 � up to 10, T2 � 11–20, T3 � more than 20; Duncan’s Mean Test.

Table 9: Comparisons of risk factors among three team size groups.

TT1 (N � 113) TT2 (N � 96) TT3 (N � 111)

Risk Factors Mean SD Mean SD Mean SD TT1 v/s TT2 TT1 v/s TT3 TT2 v/s TT3 F-value

SRS Variability 2.99 1.13 2.99 1.06 3.18 0.98 - - - 1.1998

Team Composition 2.70 1.12 2.56 1.00 2.93 0.94 - - * 3.1201*

Control Processes 2.47 1.10 2.46 1.06 2.60 0.99 - - - 0.5424

Dependability 2.76 1.15 2.75 1.19 2.98 1.07 - - - 1.4238

Note. TT1 � up to 9 months, TT2 � 10–19 months, TT3 � more than 19; Duncan’s Mean Test.*Significant at 0.05 level.

Table 10: Comparisons of risk factors among three total time groups.



AP

ER

S

that have an impact on the success ofsoftware projects. These four categoriesof software risks do affect the success ofsoftware projects in India. These riskdimensions are SRS variability risk,team composition risk, controlprocesses risk, and dependability risk.These risks have also been ranked onthe basis of their mean values, and ithas been determined that SRS variabil-ity risk has the maximum effect on thesuccess of the software projects. On fur-ther exploration, it has been found thatthere is a difference in the perceptionsof software executives (based on theirpersonal attributes and project attrib-utes) toward these risk dimensions,wherein senior managers perceivethese risks to be more controllable andhaving less impact on the success of theproject compared with the perspectivesof junior managers.

The analysis of risk dimensions andperceptions of individuals regardingthese dimensions is extremely helpfulfor both practitioners and academiciansbecause it helps in disentangling theperceptions about risk factors at variouslevels of demographic characteristicsand also explains the variances amongvarious groups of project characteristics.This will enable organizations to accu-rately gauge the software risk dimen-sions based on the designation andexperience of employees and the dura-tion, team size, and value of projects.

This study illuminates the existing the-oretical foundations regarding software

risks by exploring the detailed andample responses provided by the vari-ous groups of experienced systemdevelopers and IT professionals.Although the respondents providedrich and fertile data for the examinationof software risks, future studies shouldincrease the sample size to enablequantitative assessments, in addition tothe qualitative assessments providedhere. In addition to the limitationsposed by the number of study partici-pants, future research should pursuethe involvement of a greater number oforganizations. Also, only software riskshave been taken into consideration;these software risks include mainlytechnical and team-related issues.There are many more risks that areexternal to projects but have a deepimpact on project success. Such risksare environmental, cultural, political,and even organization-specific. Thisstudy was based on a generic pattern ofthe software industry in India. Moreauthentic results can emerge if organi-zation-specific factors are chosen forthe study. These constraints serve aslimitations to the overall generalizationof this study. Further research shouldbe undertaken to find out ways to amal-gamate the perceptions of less experi-enced, lower-level personnel with thoseof senior, upper-level IT professionals,and to study how these different views aremanaged to promote a more unified andconsistent approach to risk manage-ment. The findings of the exploratory

studies provide normative guidance toboth junior and senior developers alike.These findings provide rich and robustevidence in support of the theoriesdeveloped and advanced by otherrecent studies; that is, the identificationof risks and intensity of risks as gov-erned by the demographic and projectcharacteristics. Now that it has beendetermined that magnitude and inten-sity of the impact of risks on softwareprojects are largely matters of percep-tion, further investigations can be con-ducted to determine the correlation ofdemographic characteristics and proj-ect characteristics with the intensity ofthe risk dimensions. �

ReferencesAddison, T., & Vallabh, S. (2002).Controlling software project risks: Anempirical study of methods used byexperienced project managers.Proceedings of SAICSIT 2002, PortElizabeth (pp. 128–140).

Agarwal, N., & Rathod, U. (2006).Defining success for software projects:An exploratory revelation. Journal ofSystems and Software, 24, 358–370.

Aharon, Y., & Ilana, L. (2010). Changingstudents perception regarding softwaredocumentation. MCIS 2010Proceedings.

Anudhe, M. D., & Mathew, S. K. (2009).Risks in offshore IT outsourcing: Aservice provider perspective. EuropeanManagement Journal, 27, 418–428.

V1 (N � 102) V2 (N � 89) V3 (N � 109)\

Risk Factors Mean SD Mean SD Mean SD V1 v/s V2 V1 v/s V3 V2 v/s V3 F-value

SRS Variability 2.93 1.17 3.12 1.06 3.13 0.94 - - - 1.1468

Team Composition 2.66 1.14 2.79 1.01 2.80 0.94 - - - 0.6530

Control Processes 2.49 1.09 2.54 1.07 2.51 1.00 - - - 0.0640

Dependability 2.72 1.23 2.87 1.16 2.93 1.00 - - - 0.9201

Note. V1 � up to US $0.70 million, V2 � US $0.71–2.00 million, V3 � more than US $2.00 million; Duncan’s Mean Test.

Table 11: Comparisons of risk factors among three value groups.


Arora, A., Arunachalam, V.S., Asundi,J., & Fernandes, R. (2001). The Indiansoftware services industry. ResearchPolicy, 30(8), 1267–1287.

Avizienis, A., Laprie, J. C., Randell, B.,& Landwehr, C. (2004). Basic conceptsand taxonomy of dependable andsecure computing. IEEE Transactionson Dependable and Secure Computing,1, 11–33.

Babich, W. (1986). Software configura-tion management. Reading, MA:Addison-Wesley.

Baccarini, D. (1996). The concept ofproject complexity: A review.International Journal of ProjectManagement, 14(4), 201–204.

Bannerman, P. L. (2008). Risk and riskmanagement in software projects: Areassessment. Journal of Systems andSoftware, 81, 2118–2133.

Barki, H., & Hartwick, J. (1989).Rethinking the concept of userinvolvement. MIS Quarterly, 13(1),53–63.

Bersoff, E. (1984). Elements of softwareconfiguration management. IEEETransactions of Software Engineering,10, 77–87.

Boehm, B. W. (Ed.). (1989).Organizational climate and culture.San Francisco, CA: Jossey-Bass.

Boehm, B. W. (1991). Software riskmanagement principles and practices.IEEE Software, 8(1), 32–41.

Bosco, G. (2004). Implicit theories ofgood leadership in the open-sourcecommunity. Retrieved from http://opensource.mit.edu/papers/bosco.pdf

Bourne, L., & Walker, D. H. T. (2004).Advancing project management inlearning organizations. The LearningOrganization, 11(1), 226–243.

Clancy, T. (1995). Chaos: IT develop-ment projects. Retrieved from http://www.standishgroup.com/msie.htm

Costa, H. R., Barros, M. D. O., &Travassos, G. H. (2007). Evaluatingsoftware project portfolio risks. Journalof Systems and Software, 80, 16–31.

Dash, R., & Dash, R. (2010). Riskassessment techniques for softwaredevelopment. European Journal ofScientific Research, 42(4), 615–622.

de Souza, S. C., Anquetil, N., & deOliveira, K. M. (2007). Which docu-mentation for software maintenance?Journal of the Brazilian ComputerSociety, 13(2), 31–44.

Dey, P. K., Kinch, J., & Ogunlana, S. O.(2007). Managing risk in softwaredevelopment projects: A case study.Industrial Management and DataSystems, 107(2), 284–303.

Faraj, S., & Sambamurthy, V. (2006).Leadership of information systemsdevelopment projects. IEEETransactions of EngineeringManagement, 53(2), 238–249.

Field, T. (1997). When BAD things hap-pen to GOOD projects. CIO, pp. 55–62.

Francalanci, C. (2001). Predicting theimplementation effort of ERP projects:Empirical evidence on SAP/R3. Journalof Information Technology, 16, 33–48.

Galorath, D. D., & Evans, M. W. (2006).Software sizing estimation and riskmanagement. Auerbach Publications.

Gioia, J. (1996, November). Twelve rea-sons why programs fail. PM Network,pp. 16–20.

Hoodat, H., & Rashidi, H. (2009).Classification and analysis of risks insoftware engineering. World Academyof Science, Engineering and Technology,56, 446–452.

Huang, H., & Trauth, E. (2007, April).Cultural influences and globally dis-tributed information systems develop-ment: Experiences from Chinese ITprofessionals. Proceedings of ACM SIG-MIS-CPR Conference, St. Louis,Missouri, USA, pp. 36–45.

Iacovou, C. L., & Nakatsu, R. (2008). Arisk profile of offshore-outsourceddevelopment projects. Communica-tions of the ACM, 51(6), 89–94.

Jannson, A. S. (2007, November/December). Software maintenance andprocess improvement by CMMI.Retrieved from http://www.utn.uu.se

/sts/cms/filarea/0801_ann-sofie_jansson.pdf

Jiang, J., & Klein, G. (2001). Softwareproject risks and development focus.Project Management Journal, 32(1)20–26.

Jones, C. (1993). Assessment and con-trol of software risks. Englewood Cliffs,NJ: Prentice-Hall.

Keil, M., Cule, P., Lyytinen, K., &Schmidt, R. (1998). A framework foridentifying software project risks.Communications of the ACM, 41(11),76–83.

Keil, M., Im, G. P., & Mahring, M.(2007). Reporting bad news on soft-ware projects: The effects of culturallyconstituted views of face-saving.Information Systems Journal, 1(791),59–87.

Keil, M., Smith, H. J., Pawlowski, S., &Jin, L. (2004). Why didn’t somebody tellme? Climate, information asymmetryand bad news about troubled projects.The DATA BASE for Advances inInformation Systems, 35(2), 65–84.

Keil, M., Tiwana, A., & Bush, A. (2002).Reconciling user and project managerperceptions of IT project risk: A Delphistudy. Information Systems Journal,12(2), 103–119.

King, J. (1994). Sketchy plans, politicsstall software development. ComputerWorld, 29(24), 81.

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

Laudise, T. M., & Nuara, L. T. (2002).How to contract for a successful e-commerce development project:Beating the odds. The Business Lawyer,58, 299–316.

Leitheiser, R. L., & Wetherbe, J. C.(1986). Service support levels: Anorganized approach to end-user com-puting. MIS Quarterly, 10, 336–350.

Linberg, K. R. (1999). Software devel-oper perceptions about software proj-ect failure: A case study. Journal ofSystems and Software, 49, 177–192.



AP

ER

S

Lyytinen, K., Mathiassen, L., &Ropponen, J. (1998). Attention shapingand software risk: A categorical analy-sis of four classical risk managementapproaches. Information SystemsResearch, 9(3), 233–255.

Masticola S. P. (2007). A simple esti-mate of the cost of software project fail-ures and the breakeven effectiveness ofproject risk management. Presented at the First International Workshop on the Economics of Software andComputation, IEEE.

Mattsson, K. M. (2008, October).Problems in agile trenches. Proceedingsof the Second ACM-IEEE InternationalSymposium on Empirical SoftwareEngineering and Measurement,Kaiserslautern, Germany.

McFarlan, W. (1982). Portfolioapproach to information systems.Journal of Systems Management, 33(1),12–19.

McLeod, G., & Smith, D. (1996).Managing IT projects. Boyd and FraserPublishing.

Morris, P. (2004, November). Metricsbased project governance. Key noteaddress from the IWSM SoftwareMeasurement Conference, Berlin,Germany. Retrieved from http://compaid.com/caiinternet/ezine/morris-metrics.pdf

Mursu, A., Soriyan, H.A., &Olufokunbi, K.C., (1996). Toward suc-cessful ISD in developing countries:First results from a Nigerian risk studyusing the delphi method. Retrievedfrom http://iris22.it.jyu.fi/iris22/pub

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

Otto, H. K., & Magee, C. L. (2006).Estimating factors affecting projecttask size in product development: Anempirical study. IEEE Transactions onEngineering Management, 53(1), 86–94.

Oz, E., & Sosik, J. (2000). Why informa-tion systems projects are abandoned: A

leadership and communication theoryand exploratory study. Journal ofComputer Information Systems, 41(1),66–78.

Oza, N., Hall, T., Rainer, A., & Grey, S.(2004). Critical factors in software out-sourcing: A pilot study. Proceedings ofthe 2004 ACM Workshop onInterdisciplinary Software EngineeringResearch (pp. 67–71).

Pan, J. (1999). Software reliability.Carnegie Mellon University. Retrievedfrom http://www.ece.cmu.edu/�koopman/des_s99/sw_reliability

Reel, J. S. (1999, May–June). Criticalsuccess factors in Software Projects.IEEE Software, pp. 18–23.

Ropponen, J., & Lyytinen, K. (2000).Components of software developmentrisk: What influences it—A projectmanager survey. IEEE Transactions onSoftware Engineering, 26(2), 98–112.

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

Schmidt, R., Lyytinen, K., Keil, M., &Cule, P. (2001). Identifying softwareproject risks: An international Delphistudy. Journal of ManagementInformation Systems, 17(4), 5–36.

Sharma, A., Gupta, A., & Khilnani, D.(2009). Identification and correlationof software project risks for excelling inIT industry. FOCUS—The InternationalJournal of Management Digest, 5(1&2),42–50.

Sherer, H. (1995). The three dimensionsof software risk: Technical, organisa-tional, and environmental. Presentedat the 28th Annual HawaiiInternational Conference on SystemSciences.

Shull, F., Rus, I., & Basili, V. (2000). Howperspective-based reading canimprove requirements inspections.Computer, 33(7), 73–79.

Smite, D. (2006). Requirements man-agement in distributed projects.

Journal of Universal KnowledgeManagement, 1(2), 69–76.

Smith, D., Eastcroft, M., Mahmood, N.,& Rode, H. (2006). Risk factors affect-ing software 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 projectstatus reporting. Information &Management, 44(2), 130–141.

Standish Group. (2009). CHAOS sum-mary. Boston, MA: Author.

Stephen, D., Keil, M., Mathiassen, M.,Shen, Y., & Tiwana, A. (2007).Attention-shaping tools, expertise, andperceived control in IT project riskassessment. Decision Support Systems,43(1), 269–283.

Thompson, R., Iacovou, C., & Smith, H.J. (2009). Biased project status reports:A survey of IS professionals.Proceedings of the 17th EuropeanConference on Information Systems.

Verner, J. M., Beecham, S., & Cerpa, N.(2010). Stakeholder dissonance:Disagreements on project outcomeand its impact on team motivationacross three countries. Proceedings ofthe 2010 Special Interest Group onManagement Information Systems’s48th Annual Conference on ComputerPersonnel Research (pp. 25–33).

Verner, J. M., Evanco, W. M., & Cerpa, N.(2007). State of the practice: Anexploratory analysis of schedule esti-mation and software project successprediction. Information and SoftwareTechnology, 49(2), 181–193.

Warkentin, M., Bekkering, E.,Johnston, A. C., & Moore, R. S. (2009).Analysis of systems development proj-ect risks: An integrative framework.The DATA BASE for Advances inInformation Systems, 40(2), 8–26.

Warkentin, M., Bekkering, E., &Moore, J. R. (2007). Risk perspectivesin systems development. Proceedingsof the Americas Conference onInformation Systems (AMCIS 2007).


Wateridge, J. (1995). IT projects: Abasis for success. International Journal of Project Management, 13(3),169–172.

Zhou, L., Vasconcelos, A., & Nunes, M.(2008). Sorting decision making in risk management through an evi-dence-based information systemsproject risk checklist. InformationManagement and Computer Security,16(2), 166–186.

Arpita Sharma holds a PhD in management andis a committed academician and devotedresearcher. She has extensive experience inteaching undergraduate and postgraduate stu-dents. She started her career as a faculty mem-ber in the Professional Development Departmentwith the Jaypee Institute of InformationTechnology (JIIT) in Noida, India, and then alsospent some time with the Jaipuria Institute ofManagement in Noida. She has published around

five research papers in international and nationaljournals of repute. She has presented a numberof papers in various conferences. Her areas ofinterest are project management, financial man-agement, and presentation and communicationskills. She is a highly motivated, innovative, andresults-oriented educator, seeking to combineacademic training in a learning-centric approachto make a solid contribution to organizationalgoals in higher education.

Santoshi Sengupta holds a PhD in managementand has been working with the Jaypee Instituteof Information Technology in Noida, for the past6 years. She started her career in January 2005in the faculty of the professional developmentdepartment at JIIT. She has to her credit around10 research publications in international andnational journals of repute and also as chaptersin books. She has presented a number of papersin international conferences both in India andabroad. She teaches organization behavior, total

quality management, presentation and commu-nication skills, English, and group and coopera-tive processes successfully to B.Tech students.She endeavors to augment herself as a commit-ted researcher and proficient teacher to impartthe best to her students. She is a highly moti-vated, inventive, and results-oriented academi-cian who seeks to provide academic trainingusing a learning-centric approach.

Aayushi Gupta, associate professor and headof the department of professional development,holds a PhD in management. She has more than10 years of teaching experience. She has guid-ed a number of PhD scholars under her and has nine research publications in internationaland national journals of repute and also hasauthored chapters in various books. She haspresented a number of papers in internationalconferences both in India and abroad. She is acommitted researcher and believes in qualitywork.

Documents

Exploring risk dimensions in the Indian software industry