RETARDATIONINSOFTWARE

FAILURERATE

“Iwanttodedicatethisbooktomywonderfulparentsforbelievingandalwaysbeingthereformeandthealmighty

God.”

-MayankJindal

“TomyhusbandPuneet,whoismyinspirationineverythingIdoandeverychoiceImake.Ialsodedicatethistomymom,whoalwayssupportedmeineveryendeavor.SheisthereasonI’mhereatall,andmademewhoIamtoday.”

-NehaGupta

“Tomywife,Jyoti,whohasalwaysbeentherethroughthehardtimesandtomyfamilywhohavealwaysbeentherefor

me,andhaveneverdoubtedmydreams,nomatterhowcrazytheymightbe.”

-SunilKumarJangir

PREFACE

Every organization has a mission. In this digital era, as organizations use automatedinformation technology (IT) systems to process their information for better support oftheir missions, risk management plays a critical role in protecting an organization’sinformation assets, and therefore its mission, from IT-related risk. An effective riskmanagementprocessisanimportantcomponentofasuccessfulITsecurityprogram.Theprincipal goal of an organization’s risk management process should be to protect theorganizationanditsabilitytoperformtheirmission,notjust itsITassets.Therefore, theriskmanagementprocess shouldnotbe treatedprimarily as a technical functioncarriedout by the IT experts who operate and manage the IT system, but as an essentialmanagementfunctionoftheorganization.

Theobjectiveofperformingriskmanagementistoenabletheorganizationtoaccomplishitsmission(s)thatincludesprovidingbettersecuritytotheITsystemsthatstore,process,or transmit organizational information and by enabling management to make well-informed risk management decisions to justify the expenditures that are part of an ITbudget and to assistmanagement in authorizing (or accrediting) the IT systems on thebasis of the supporting documentation resulting from the performance of riskmanagement.

i

RetardationinSoftwareFailureRate

TABLEOFCONTENTS

HEADING PageNo.

Preface i

Chapter1.Introduction 1

1.1.Whattitle“RetardationinSoftwareFailureRate”means? 1

1.2.ShortDescription 1

1.3.MeritsofRiskManagement 7

1.4.DemeritsofRiskManagement 10

1.5.ApplicationsofRiskManagementActivities 11

Chapter2.LiteratureReview 15

2.1.WhatismeantbyRisks? 15

2.2.EvolutionofRiskManagement 31

2.3.NeedforRiskManagement 52

Chapter3.ImplementationofRiskManagementinSoftwareProjectDevelopment 55

3.1.IdentifyingRisks 55

3.2.ProblemsofRiskAnalysisanditsneed 61

3.3.RiskManagementProcess 70

3.4.OtheroptionsavailableforRiskManagement 76

Chapter4.CurrentresearchonSystematicRiskManagement

83

4.1.Additionofnewfeaturestomanagerisks 83

4.2.IndustriestalksaboutRiskManagement 86

4.3.OtherapproachestoRiskManagement 100

Conclusion

ResearchinFuture

Bibliography

I.ResearchPapers

II.Pdffiles

III.BooksReferred

IV.Othersources

AboutAuthor(s)

ListofFigures

Figure1:DefinitionofriskintheRiskitmethod 15

Figure2:Riskmanagementprocessinputsandoutputs 16

Figure3:SEI’sriskmanagementcycle 21

Figure4:RiskManagementProcess 38

Figure5:ModelofindividualbehavioronFailure/Success 48

Figure6:RiskThermostat 49

Figure7:‘SoftRisk’model’sdiagram 56

Figure8:SWIforEK,DCandQmethodology 58

Figure9:RiskManagementProcess 61

Figure10:OnewayofcategorizingrisksinOrganization 75

Figure11:BoehmRiskManagement 78

Figure12:Wallmüller’sRiskManagement 79

Figure13:Kontio’sRisk-ManagementProcess 81

ListofTables

Table1:Boehm’sriskmanagementmodel 20

Table2:SEI’srisktaxonomy 22

Table3:SoftwareRequirementRisks 26

Table4:SoftwareCostRisks 26

Table5:SoftwareSchedulingRisks

27

Table6:SoftwareBusinessRisks

27

Table7:SoftwareQualityRisks

28

Table8:Requirementsforthemethoddevelopment

43

Table9:Requirementsfortheimprovementframework

45

Table10:Listofempiricalstudiesandtheirobjectives

46

Table11:BoehmTenriskFactors

61

RetardationinSoftwareFailureRate

CHAPTER-1

Introduction

1.1What“RetardationinSoftwareFailureRate”means?

In today’s scenario, Software products are gaining more popularity due to their strongneedinenterprisebusiness.Inpastdecades,especiallyattheendof20thcentury,andthebeginning of 21st century, there is rapid growth in automation of different activities.Automationisdonethroughsoftwares.Thereoccurmanysoftwarefailuresevenafterthedeploymentstage.Earlierthesoftwaredevelopmentprojectsconductedriskmanagementusing different ad hoc approaches,without following any systematicmethodologies butnowwithgrowthofsoftware,industrieshaverealizedtheimportanceofriskmanagementasithelpsindecreasingthechancesofprojectfailures.McManusin2004identifiedthat65%of the project failures are accounted bymanagement issues and 35%by technicalissues.These failure reports force to develop somemethodology to retard this softwarefailure rate. So, this is all about the title “Retardation in software failure rate”. So thisreport addresses on implementing project risk management practices in softwaredevelopment environment and intends to motivate risk identification, analysis and riskmitigationinglobalsoftwareprojects.

1.2ShortDescription

Although, significant progress has been made in software development methodologies,softwareprojectfailurescontinuetoexist.Previousworkonriskmanagementhasfoundseveral risk factors andhas developedmethods for avoiding those factors fromcausingfailuresofsoftwareprojects.However,softwaredevelopmentremainsariskyundertakingwhere decisionsmust bemadewithout complete information.Another approach to risk

management is to concentrate on those making decisions as agents of an organizationratherthanjust themethodstheyuse.Weproposethatthebehaviourofdecisionmakersaffectedbyriskpropensityandmotivationiscriticaltotheoutcomeofasoftwareproject.[1]

Thechallengesandrealitiesinapplyingeffectivesoftwareriskmanagementprocessesaredifficult, in particular integrating the risk management processes into softwaredevelopment organizations. However, the benefits of implementing effective riskmanagement tools and techniques in software development project are equally great.Currentperceptionsandemerging trendsofvarious software riskmanagementpracticesare reviewed and risks specific to software development projects are identified.Implementing effective risk management process will succeed by changing theorganizationalculture.[2]

Software engineering has attracted the recent focus of academia and researchers byprovidingthemmeansofeffectivesoftwaredevelopment.Theeffectiveriskmanagementhas alsoplayed avital role ismaking the softwaredevelopmentpracticesmore reliableandorganized.Ampleconsiderationisbeinggiventothesoftwareriskanalysisandthathas enabled the more reliable software management. With emergence of the need formanagingtherisksinsoftware,itisessentialthatsuitablemethodologybeidentifiedforidentifyingtherisks.[3]

SoftwareRiskManagement is a proactive approach forminimizing the uncertainty andpotential loss associated with a project. Some categories of risk include product size,business impact, customer-related, process, technology, development environment,staffing(sizeandexperience),schedule,andcost.Providinginsightstosupportinformeddecision making is the primary objective of Risk Management. In contrast, RiskManagement practice concentrates on performing bottom-up, detailed, continuousassessment of risk and opportunity. It focuses on addressing the day-to-day operationalrisksthataprogramfaces.RiskManagementfollowsatwo-stage,repeatableanditerativeprocess of assessment (i.e., the identification, estimation and evaluation of the risksconfronting a program) and management (i.e., the planning for, monitoring of, andcontrollingofthemeanstoeliminateorreducethelikelihoodorconsequencesoftherisksdiscovered). It is performed continually over the life of a program, from initiation toretirement.[4]

RiskManagementcanbedefinedasa systematicprocess for identifying,analyzingandcontrolling risks in projects or organizations. Definitions and illustrations of risks are

given especially by a list of ten risk factors, which occur most frequently in IT andSoftwareprojects.Forcomplex,high-riskprojectsitisveryusefultoimplementaformalrisk-managementprocess,supportedbyeffectivemethodsintheindividualprocesssteps.As variants, risk-management processes according to Barry Boehm, Ernest WallmüllerandJyrkiKontioarepresented.Theimportanceofasoundoperationalpreparationofeachstepoftherisk-managementprocessisemphasizedandillustratedbyexamples. Inorderto increase the likelihood of a project reaching a successful conclusion, the risks orpotential problems for a project need to be identified at an early stage and appropriatecountermeasuresdeveloped.TomGilbput it inanutshellwith the followingwords:“Ifyoudon’tactivelyattacktherisks, theriskswillactivelyattackyou.”Experienceshows[Boeh89] that handling risks proactively, as is the case with risk management, is lessexpensive thancorrectingproblems in theaftermath. [5]Properprojectdecision-makingrequires that riskmanagement and risk analysis techniquesbeapplied in order to guidemanagementinmakingbetterdecisions.Costestimatesattempttodefineprojectsassinglepointvalueswhereasvirtuallyallprojectvariablesarevariableandmaydeviatefromthevaluesassumedinpreparingtheoriginalestimate.[6]

Despite the fact that riskmanagement has been with us for some time, little has beenreportedaboutitsindustrialstatus,itsco-existencewiththedevelopmentmodels,anditscompliance to standard risk management process models. For many years, riskmanagement has been known within various traditional domains such as business,manufacturing,healthcare,warfare,sociology,andthelike.Ithasbeenconsideredtobeanenablerof risk-taking.By identifyingand controlling the risks, onemaymakebetterand more daring decisions when taking on complex challenging projects or whenexploringnewunknowngrounds [7].Recently,however, it hasbecome recognizedas abestpracticeinthesoftwareindustry[8].Reasonsaremany.Someofthemareincreasedbusiness volatility, constantly changing technologies, improved customer satisfaction,globalization, substantial impact on business disruption, and the like [9][10]. Muchresearchhasbeenconductedinthesoftwareriskmanagementfieldinthepastdecades,forinstanceby[11][12][7][13][14].Ithasresultedinanumberofframeworksandmodelssuggesting risk types, risk management strategies, process models, and variousperformancemeasures[15][16][17][18][19].

Despite this, little is known about the state of practicewithin riskmanagement. To theknowledgeoftheauthorsofthispaper,therearenopublicationsreportingonthestatusof

the overall risk management process and on how it integrates with the developmentprocess.Hence,wedareclaimthatthesoftwarecommunitycurrentlylacksinsightintotheindustrialstateofriskmanagementpractice.Majorgoalsare:(1)tofindoutthestatusofriskmanagement process in the industry today, (2) to evaluate standardprocessmodelsagainst the industrial practice, (3) to find out how the industry has integrated riskmanagement with their development processes, (4) to identify issues that might aid inimprovingtheintegratedprocess,andfinally,(5)tofindoutthedifferencesbetweenagileandotherdevelopmentapproaches.[20]

The risk connected with the wide application of information technologies in businessgrowstogetherwiththeincreaseoforganization’scorrelationfromitscustomers,businesspartnersandoutsourcedoperations.Technologicalprogressgeneratesdependencieswhichevokegrowthofdiversities,complexity,non-descriptivenessandquantityofriskfactors.In insufficient investments on information security the issue of IT risk assessmentbecomesmoresignificant,concentratingonsearchingoptimalproportionbetweenthreatsand costs of IT systems protections. In such a dynamic development of InformationTechnologiesthetimeneededforappropriatereactiononriskisdecidedlyshortened.Thelack of appropriate preparation may lead the company to collapse, thus appropriatereactiononriskconstitutesaboutpossibilitiesofsurvivalanddevelopmentofenterprise.The problemof IT riskmanagement is very complex issue.One of themost importantstages of this process is risk analysis, used for optimization, and correctly forminimizationsoflossesconnectedwithrisk.Oneofitskeyelementsisevaluationstageorriskassessment.Theliteratureofsubjectveryoftenskipstheissueofquantitativemethodsof risk assessment, only concentrating on rare, chosen qualitative methods. Also inliteratureconcerningsecurityofITsystemsthisproblemistotallyskippedorhasnogreatmeaning. It is caused by huge difficulty in conduct of this process and selection ofappropriatemethodsofmeasures.Thatiswhyinpublicationsfromthisscopetheremostoften are presented simple qualitative methods, where assessment of InformationTechnology risk value is connected only with qualitative description, and definition ofquality scales for frequencies of threat occurrence or description of so called threatsscenarios.[21]

Theoreticiansandpractitionersdonotgiveoneuniversaldefinition,thusthereexistmanyof them in the literature.According to ISACA, the risk isapossibilityofoccurrenceofevent, which will have undesirable effect on a given organization and it’s InformationSystems[22].Thescienceabouttheriskisdevelopedinmostofscientificdisciplinesandapplied in all technologies. There should be remembered that in different scientific

disciplines,theriskisperceiveddifferently.Alsoindifferentformsofbusinessactivitywewillhaveindividualformsofrisk.Othertypesofriskwilloccurinproductionenterpriseandotheronesforexample in financialsector. In thecontextof ITsystemssecurity theriskofITsystemsisoverallmeasureofprobabilityandseriousnessofsituation,inwhichagiven threat uses specificweakness, causing loss or damageof systemassets, thereforeindirectordirectlossfororganization.ITriskitisthethreatthatInformationTechnologyappliedinagivenorganization(independentlyfromitstypeandscaleofbusinessactivity)[23]:

−Doesnotfulfillbusinessrequirements,

−Doesnotensureappropriateintegrity,securityandavailability,

−Wasnotappropriatelyimplementedanddoesnotworkaccordingtoassumptions.

ITriskmanagementcurrentlyplaysmoreandmoreimportantroleinalmostallaspectsofcontemporaryorganizations’functionality.Itrequiresreliableandcyclicalrealizationofitskeytaskwhichisriskanalysis.Literatureofsubjectpresentsproblemsofriskanalysisindifferentway; themost often skipped or selectively treated the problem of quantitativemethodsapplicationforthepurposeofriskanalysis.[24]

Software Project Management (SPM) has become a critical task. It involves themanagementofall issuesinvolvedinthedevelopmentofsoftwareprojectnamelyscopeandobjectiveidentification,evaluation,planning,projectdevelopmentmethods,softwareeffortandcostestimation,activityplanning,monitoringandcontrol,riskmanagementandresourceallocation[25,26,27].Softwareprojectsfacemanyrisksintheirlifecycle.Riskisanypotentialsituationoreventthatcouldnegativelyaffectaproject’sability.Ariskisanexposure to loss or injury or a factor, thing, element, or course that involves uncertaindanger[28,29,30].

ProjectRiskManagementInstitutehasdevelopedguidelinesforriskmanagement.Theseguidelinesincluderiskmanagementplanning,riskidentification,qualitativeriskanalysis,quantitative risk analysis, risk response planning and riskmonitoring and tracking. Foreachstep,itdefinesinputs,tools,techniquesandoutputs[31].Softwareriskmanagementis a part of SPM. It is very important for software projects. Software riskmanagementstepswerepresentedbyBarryBoehm[32]andpossesstwoprimarysteps.Thefirstoneisrisk assessment and the second is risk control. Risk assessment involves riskidentification,riskanalysisandriskprioritization.Riskidentificationproducesalistoftheproject risk items using several techniques [33, 34, 35]. Risk analysis assesses the loss

probabilityand lossmagnitudeforeach identifiedriskandriskprioritizationproducesarankedorderingof theriskitemsidentifiedandanalyzed.Variousmethodsexistfor riskanalysis[27].Theriskmanagementcyclerepresentsbasicactivities,processesandmainflowsofinformationbetweenthem[36].

Advocatesofsoftwareriskmanagementclaimthatbyidentifyingandanalyzingthreatstosuccess (i.e. risks) action can be taken to reduce the chance of failure of a project. Itremainsasadstatisticthattoomanysoftwaredevelopmentprojectsendinfailure[37,38,39,40].Asmanyas80percentofallsoftwareprojectsrunovertheirbudgets[40],withthe“average”softwareprojectexceedingitsbudgetby50percent[37,52].Advocatesofsoftware project risk management claim that by identifying and analyzing threats tosuccess, action can be taken to reduce the chance of failure [41,42,43].Through severalfactors have been published in the literature (e.g.,[44,45,46,47,48,49,50]), ourunderstanding of the typical risk factors is still inadequate. The software projectmanagement literature views riskmanagement as two-stage process: assessing the risk,andtakingactiontocontrolit[46,43,51].

Thefirst stage, riskassessment,consistsof threesteps: (1) identificationof risk factors,(2)estimationofthelikelihoodforeachriskfactortooccur,alongwithpotentialdamagefromtherisk,and(3)anevolutionoftotalriskexposure.Severalmethodsforidentifyingrisk factors have been suggested, such as scenarios, examination of past or analogoussituations,brainstorming,orothercreativemethods(seee.g.,[46,43,47]).Further,themostwidely cited studies on software risk (i.e., [44, 46, 48]) drew their data from large,mainframebasedprojectsundertakenduringthe1970sand1980s.

Limiting the focus of risk analysis to quantifiable factors and using a narrowunderstanding of the scope of a software project are major contributors to significantsoftware failures. A Software Development Impact Statement (SoDIS) process ispresentedwhichextendstheconceptofsoftwareriskinthreeways;itmovesbeyondthelimited approach of schedule, budget, and function, it adds qualitative elements, anditrecognizesprojectstakeholdersbeyondthoseconsideredintypicalriskanalysis.

As the typesof risks increase, the rangeofstakeholders thatneed tobeconsideredalsoexpands.Usingthisexpandedviewofriskanalysisreducedoreliminatedtheimpactsofmanypreviously undetected risks of software development. The SoDIS process and itssoftwareassociatedevelopmenttaskswithrelevantstakeholdersthroughtheapplicationofstructured questions. This process was incorporated effectively into the software

developmentlifecycleandappliedtosoftwaredevelopmentprojectsindifferentdomainsonseveralcontinents.ThesuccessesoftheSoDISprocessprovidestrongevidencethatasignificantside-effectofnarrowingprojectobjectivesisarootcauseofITprojectfailures.[53]

Therearemanyconceptsaboutsoftwareriskmanagement[33,34,35,36].Herearesomemajorconceptsasfollows:

A.RiskIndex

Asrisksareidentified,theycanbecategorizedbyimpact(I)andlikelihoodofoccurrence(LO).Whenthesetwofactorsaremultiplied,riskscanbecharacterizedashigh,medium,or low.Riskprioritizedwithina risk index (RI)bya singlemeasure thatdetermines itsimportancetotheprojectandtherelativevisibility,responseandreportingrequired.Thisindexisnecessaryforprioritizationofrisk[33,29].

B.RiskAnalysis

There are a few well-known types of risk analysis that can be used [31]. In softwareengineering,riskanalysisisusedtoidentifythehigh-riskelementsofaproject.Itprovideswaysofdocumentingtheimpactofriskmitigationstrategies.Riskanalysishasalsobeenshowntobeimportant inthesoftwaredesignphasetoevaluatecriticalityof thesystem,whererisksareanalyzedandnecessarycountermeasuresareintroduced[72].Thepurposeof risk analysis is to understand risk better and to verify and correct attributes. Asuccessful analysis includes essential elements like problem definition, problemformulation,datacollection[73].

C.RiskAssessment

Risk assessment incorporates riskmanagement and risk analysis.Many risk assessmentmethodologiesexist [74] that focusondifferent typesof risks.Riskassessment requirescorrect descriptions of the target system and all security features. For assessment to beuseful, a risk referent level must be defined. For most software projects; performance,cost,supportandschedulealsorepresentriskreferentlevels[33,35].

Corporation sake risk management very seriously-recent surveys find that riskmanagementisrankedbyfinancialexecutivesasoneoftheirmostimportantobjectives.’

Given its real-world prominence, one might guess that the topic of risk managementwould command a great deal of attention from researchers in finance, and thatpractitionerswouldthereforehaveawelldevelopedbodyofwisdomfromwhichtodrawinformulatinghedgingstrateses.Suchaguesswould,however,beatbestonlypartiallycorrect.Financetheorydoesdoagoodjobofinstructingfirmsontheimplementationofhedges.Forexample,ifarefiningcompanydecidesthatitwantstouseoptionstoreduceitsexposuretooilpricesbyacertainamount,aBlack-Scholestypemodelcanhelpthecompanycalculatethenumberofcontractsneeded.Indeed,thereisanextensiveliteraturethat covers numerous practical aspects of what might be termed “hedgingmechanics,”from the computation of hedge ratios to the institutional peculiarities of individualcontracts.[54]

In mature engineering disciplines, risk management has been de rigeur for centuries.WhenMichelangelosetouttoraisethedomeofSt.Petersin1547,hewaswellawareofthepotentialcollapsezonesunderthestaging,thepossibilityofmaterialsfailure,andthehumancapacityforerror.Foreachof thesemajorriskshepreparedamitigationplan:afallback,asafetyfactor,oranalternative.Today,weroutinelypracticeriskmanagementinour stewardship of the environment, in planning financial strategy, in constructionengineering,andinmedicine.[55]

1.3MeritsofRiskManagement

Consequencesofnotusingriskmanagement:Burchett 1999 stated that riskmanagementpart is the essential part of decisionmakingprocess of all construction companies. Easy, risk and uncertainty are the destructive innatureforsomeconstructionprojects.Riskcanbeahindranceinthewayofperformance,pro-destructivityandqualityandalsotobudget.Wysocki2001statesthattheconceptofRiskManagement isnotall thateasy, it iseasy to talkofRMbenefitsbut touse itandbringintopracticeisaattentionseekingjob.Thisisbecauseofthepressureofdeadlineson project managers which exists or indeed forces them to catch up with their workrather than spending time on planning and preparing work. It is advised that projectmanagersinsteadofgeneratingpresswemusttrytosortoutthingsinsuchamannerthatadetailedprojectplanthatisaddedupwithsoundRiskManagementshouldbeconsideredmore.Aspoorplanninghaveadverseeffectson theproject, suchasschedulesteps, lowquality,budgetaryproblemsetc.

Riskmanagementbenefits:Riskmanagementofprojectisthethingwhicheveryprojectmanagerfacesindaytodaylifeso ismorespontaneous thanpractical. If the risk in theproject isnot identifiedandmanagedproperlytheconsequencescouldbepenaltieslike-

a.Overspend

b.Overrun

c.Poorprojectperformance

d.Lossofreputation

Benefitsofriskmanagementare-

1.Increasingawarenessofriskamongtheprojectteam.

2.Keepingacontrolonexposuretorisk.

3.Minimizinglossrelatedtofinance.

4.Projectprogrammethatarepre-informedtohelptomeetthetargets.

5.Improvisationinqualityofproject.

6.Enhancingthereputationintermsofapropersystemofriskidentification,assessmentandcontrol.

Toachieve theseprojectmanagersmust locateand identify riskatvariousstagesof lifecycle of project, from initial level till the end. It is also essential to keep a check onoperational, maintenance and other phases of the project. Managing risk in a projectshould be engrossed in a project for goodmanagement.However,RiskManagement isoftenseenbymanyasanactivityfordevelopedorestablishedprojectactivities.

ProjectmanagersneedtofocusmoreonprojectRiskManagementintermsofgoalsandinteractionwithother companies.For aneffectiveRiskManagement a formal approachneedstobefollowedthatensuresthatitisdoneinastructuredandsystematicmannerinordertoidentifyandmanagealltheriskeffectively.Theprincipalbenefitsare-

1.Managingriskinordertoreduceexposuretorisk.

2.Minimizelossesintermsoffinance.

3.Improvisationinprojectintermsofcosteffectiveness,timeandtarget.

4.Provisionofaframeworkforreportingaproject.

Fromasurveyitisfoundthatbyusingriskmanagement,wehave-

MinimizeRisk90%

Minimizeclaimsanddisputes68%

Longtermcostsavings63%

Qualityimprovement63%

Quickriskresponse58%

Solutionsalternatives55%

TheadvantagesofRiskManagementaretheminimizationofrisk,long-termcostsavings,qualityimprovements,andquickriskresponses.Mostofthecorrespondentsprovidedallthese advantages as cited.However, one correspondent alsoquoted theminimizationofclaimsanddisputeasitsadvantagebytheprojecthavingclearbaseline.[56]

RiskAnalysisisoftenperformedusingspreadsheetsandrandomnumbergenerators,bestcase/worst case scenarios, or sensitivity analysis. While these approaches have someutility,ifusedwithcautionandiftheirlimitationsarerecognized,itisfarmorepractical,andinmostcasesrequireslesseffort,touseMonteCarlosoftwareapproaches.Withthissoftware one can estimate cost overrun probability and the amount of contingencyrequired to reduce the overrun probability to an acceptable level. The software alsoenablestheprojectprofessionaltoexplorealternateprojectscenariosquicklyinordertodeterminetheoptimumsolutionforvirtuallyanyeconomicdecision,somethingwhichisoftennotpracticalorfeasiblewithmanualmethods.Thesoftwarecanprovideanestimateofrequiredcontingencytoavoidoverrunsatanydesiredprobabilitylevel.Itcanidentifythe required contingency for each critical project item and it can identify those itemswithin the estimatewhich contributemost significantly to project risk, aswell as thosewhichaffordthegreatestareasofopportunity.Perhapsthemostinfluentialpioneerinthefield of project risk analysis is Michael Curran, president of Decision SciencesCorporation in St. Louis, Missouri. Curran (1976, 1988, 1989, 1998) has writtenextensively on project risk analysis and range estimating approaches and developed thefirst major piece of software for project risk analysis, Range Estimating Program forPersonal Computers (REP/PC). Curran’s pioneering work began in 1964 and was

promptedbyanarticleintheHarvardBusinessReview,Jan/Feb1964issueentitled“RiskAnalysis in Capital Investment” by David B. Hertz. Curran recognized that, althoughHertzneverusedtheterm,thearticlewasaboutMonteCarloSimulationandhowitcouldbeusedtoaddresskeyissuesintheproblemofcapitalplanning.MonteCarloSimulationtechniqueshadcomeintoprominenceinthe1940swhentheywereusedingametheoryandwereappliedtoansweraprobleminparticlephysicsintheManhattanProject,i.e.,thedevelopment of the atomic bomb. It wasn’t long before other scientists and engineersrealized the power ofMonteCarlo and began applying itmanyways.But in theHertzarticle Curran saw that for the first time someone was suggesting its use in businesspractice.Thismadesomuchsense toCurran that in1968he formedDecisionSciencesCorporationwhichhaspioneeredthefieldofprojectriskanalysisintheUnitedStates.[6]

1.4DemeritsofRiskManagement

RiskmanagementproblemsTraditionallytheviewaboutriskisnegative,representslossandadverseofilleffects.Butsomeguidelinesoncurrentriskincludethepossiblesituationwherethereisµupsideriskor opportunity, where there is certain risk or uncertainties that have a beneficialconsequenceinachievingobjectives.Inspiteofthistheorymostlyriskprocessisappliedas managing threats and the approach towards opportunity management is stilloverlooked.Thetoolsandtechniquesthatareavailable to thepractitionersmainlyfocusonthenegativeside.Davey(2001)statedthatmajorlyriskmanagementconcentratesonprojectproblemsthatarenegative.Butriskcanalsocontainpositivity.Ariskcanbothbeathreataswellasanopportunity.Ifitisabletoidentifytheriskitcanturnedoutbeanopportunityandcanworknotonlyonidentifyingproblemsbutalsorealizingthebenefits.Tomake a project success, expert advice should always be considered.The problem isfacing expert advice is that they are very often and short but the real problemwe facedaily is over looked. Risk Management can make an essential contribution to a goodprojectmanagement.Ramgopal(2003)mentionedthatcurrentRiskManagementisonlylimitedtomanagingthreatswhichcreatesalimitationandhindersincontributionofriskmanagementinenhancingprojectperformance.Chapman(2002)suggestedthatR.Mnowfocuslimitedarewhichrestricts itscontributioninbettermentofprojectperformance.It

alsohasbeenraisedanargumentthatdemandingawideperspectiveformanagingrisksoruncertainty.[56]

Theproblemsofriskanalysiscanbeaddressedinseveralwaysincluding:

expandingthelistofgenericrisks,

maintainingfocusonthebroaderprojectgoals,and

extendingthelistofconsideredprojectstakeholders.[53]

Fromasurveyitisfoundthatbynotusingriskmanagement,wehave-

Timeconsuming58%

Unforeseenrisk30%

Consumemoreresourcetoconduct8%

The analysis clearly shows that the advantages of Risk Management surpass thedisadvantages of it. The disadvantages of Risk Management are process being veryobjectiveandsubjective,involvementofuncontrollablevariables,andoverdependenceoneasymethods for solving complex process. The other drawback is the non-informationsharingbetweenhighermanagementandbottomgroupresultingintobottomgroupbeingisolatedfromtheprocess.

Isriskmanagementundertakenatanearlystageinprojectmanagement?

The purpose of this dissertation is to bring out the significance or importance ofRiskManagement inconstruction industryatdifferentstagesspeciallyat theconceptualstageManagementassessmentofriskbeneficialduringtheconceptualstage’andtheaimis todeterminehowmanyprofessionalprojectmanagers in theconstruction industry,orhasprojectmanagersintheirorganizationusesRiskManagementintheirprojects,duringtheconceptualstage.[56]

1.5ApplicationsofRiskManagementActivities

RiskmanagementisaprocessthatisappliedthroughouttheSDLCphasestoidentifyrisksand tohandle thembeforeharming theproject.Applicationsof riskmanagement are in

projectdevelopment.Inindustriesusedin:

Enterpriseriskmanagement

Inenterpriseriskmanagement,ariskisdefinedasapossibleeventorcircumstancethatcanhavenegativeinfluencesontheenterpriseinquestion.Itsimpactcanbeontheveryexistence,theresources(humanandcapital),theproductsandservices,orthecustomersoftheenterprise,aswellasexternalimpactsonsociety,markets,ortheenvironment.Inafinancialinstitution,enterpriseriskmanagementisnormallythoughtofasthecombinationofcreditrisk,interestrateriskorassetliabilitymanagement,marketrisk,andoperationalrisk.Inthemoregeneralcase,everyprobableriskcanhaveapre-formulatedplantodealwithitspossibleconsequences(toensurecontingencyiftheriskbecomesaliability).Riskin a project or process canbedue either toSpecialCauseVariationorCommonCauseVariationandrequiresappropriatetreatment.

RiskmanagementactivitiesasappliedtoprojectmanagementInprojectmanagement,riskmanagementincludesthefollowingactivities:

Planninghowriskwillbemanagedintheparticularproject.Plansshouldincluderiskmanagementtasks,responsibilities,activitiesandbudget.

Assigning a riskofficer - a teammemberother than aprojectmanagerwho isresponsible for foreseeingpotentialprojectproblems.Typicalcharacteristicof riskofficerisahealthyskepticism.

Maintaining live project risk database. Each risk should have the followingattributes: opening date, title, short description, probability and importance.Optionallyariskmayhaveanassignedpersonresponsiblefor its resolutionandadatebywhichtheriskmustberesolved.

Creatinganonymousriskreportingchannel.Eachteammembershouldhavethepossibilitytoreportrisksthathe/sheforeseesintheproject.

Preparingmitigationplansforrisksthatarechosentobemitigated.Thepurposeofthemitigationplan is to describehow this particular riskwill be handled–what,when,bywhoandhowwill itbedone toavoid itorminimizeconsequences if itbecomesaliability.

Summarizingplannedandfacedrisks,effectivenessofmitigationactivities,andeffortspentfortheriskmanagement.

Riskmanagementformegaprojects

Megaprojects (sometimes also called “major programs”) are extremely large-scaleinvestment projects, typically costingmore thanUS$1billionper project.Megaprojectsinclude bridges, tunnels, highways, railways, airports, seaports, power plants, dams,wastewater projects, coastal flood protection schemes, oil and natural gas extractionprojects, public buildings, information technology systems, aerospace projects, anddefence systems. Megaprojects have been shown to be particularly risky in terms offinance, safety, and social and environmental impacts. Risk management is thereforeparticularly pertinent formegaprojects and specialmethods and special education havebeendevelopedforsuchriskmanagement.[57][58]

RiskmanagementofInformationTechnologyInformationtechnologyis increasinglypervasive inmodern life ineverysector. [59,60,61]ITriskisariskrelatedtoinformationtechnology.Thisisarelativelynewtermduetoan increasing awareness that informationsecurity is simply one facet of amultitude ofrisks that are relevant to IT and the real world processes it supports. A number ofmethodologies have been developed to deal with this kind of risk. ISACA‘s Risk ITframeworktiesITrisktoEnterpriseriskmanagement.

RiskmanagementtechniquesinpetroleumandnaturalgasFor the offshore oil and gas industry, operational riskmanagement is regulated by thesafetycaseregimeinmanycountries.HazardidentificationandriskassessmenttoolsandtechniquesaredescribedintheinternationalstandardISO17776:2000,andorganizationssuch as the IADC (InternationalAssociation ofDrillingContractors) publish guidelinesforHSECasedevelopmentwhicharebasedontheISOstandard.Further,diagrammaticrepresentationsofhazardouseventsareoftenexpectedbygovernmentalregulatorsaspartofriskmanagementinsafetycasesubmissions;theseareknownasbow-tiediagrams.Thetechniqueisalsousedbyorganizationsandregulatorsinmining,aviation,health,defense,industrialandfinance.[62]

PositiveRiskManagement

PositiveRiskManagement is an approach that recognizes the importanceof thehumanfactorandofindividualdifferencesinpropensityforrisktaking.Itdrawsfromtheworkofa number of academics andprofessionalswhohave expressed concerns about scientificrigor of the wider risk management debate [63], or who have made a contributionemphasizingthehumandimensionofrisk[64][65]

Firstly, it recognizes that any object or situation can be rendered hazardous by theinvolvementofsomeonewithaninappropriatedispositiontowardsrisk;whethertoorisktakingortooriskaverse.Secondly,itrecognizesthatriskisaninevitableandeverpresentelementthroughoutlife:fromconceptionthroughtothepointattheendoflifewhenwefinallyloseourpersonalbattlewithlifethreateningrisk.Thirdly,itrecognizesthateveryindividualhasaparticularorientationtowardsrisk;whileatoneextremepeoplemaybynature be timid, anxious and fearful, others will be adventurous, impulsive and almostoblivious to danger.These differences are evident in thewaywe drive our cars, in ourdiets, inour relationships, inourcareers.Finally,PositiveRiskManagement recognizesthat risk taking is essential to all enterprise, creativity, heroism, education, scientificadvance - in fact to any activity and all the initiatives that have contributed to ourevolutionary success and civilization. It is worth noting howmany enjoyable activitiesinvolvefearandwillinglyembracerisktaking.

Within the entireRiskManagement literature youwill find little or no reference to thehumanpartoftheriskequationotherthanwhatmightbeimpliedbytheterm‘compliant’.This illustrates the narrow focus that is a hall mark of much current riskmanagementpractice.Thissituationarisesfromthebasicpremisesoftraditionalriskmanagementandthepracticesassociatedwithhealthandsafetywithintheworkingenvironment.Thereisabasiclogictotheideathatanyaccidentmustreflectsomekindofoversightorsituationalpredisposition that, if identified, can be rectified. But, largely due to an almostinstitutionalized neglect of the human factor, this situationally focused paradigm hasgrown tendrils that reach intoeverycornerofmodern lifeand into situationswhere theunintendednegativeconsequencesthreatentooutweighthebenefits.

PositiveRiskManagementviewsbothrisktakingandriskaversionascomplementaryandof equal value and importance within the appropriate context. As such, it is seen ascomplementarytothetraditionalriskmanagementparadigm.Itintroducesamuchneededbalance to riskmanagement practices and puts greater onus onmanagement skills anddecisionmaking.Itisthedynamicapproachofthefootballmanagerwhoappreciatesthe

offensive and defensive talentswithin the available pool of players. Every organizationhasrolesbettersuitedtorisktakersandrolesbettersuitedtotheriskaverse.Thetaskofmanagement is to ensure that the rightpeople areplaced in each job.Thegraveyardofformergreatsislitteredwithexampleswherethebalanceofriskwentseriouslyawry;theENRON and RBS stories have become iconic references in the pantheon of corporategovernanceandcorporatemortality.EastmanKodakmightbeanomineefortheoppositepole-thecorporatelyriskaverse.

Positive Risk Management relies on the ability to identify individual differences inpropensityforrisk taking.Thesciencein thisareahasbeendevelopingrapidlyover thepast decadewithin the domainof personality assessment.Once an area of almost tribalallegiancetodifferentschoolsofthought,todaythereiswidespreadconsensusaboutthestructure of personality assessment and its status within the framework of the crossdisciplinaryprogressbeingmadeinourunderstandingofHumanNature.TheFiveFactorModel(FFM)[66]ofpersonalityhasbeenshowntohaverelevanceacrossmanydifferentcultures, to remain consistent over adult working life and to be significantly heritable.Within this framework there are many strands which have a clear relationship to risktoleranceandrisktaking.Forexample,Eysenck(1973)reportsthatpersonalityinfluenceswhetherwefocusonwhatmightgowrongoronpotentialbenefits[67];Nicholsonetal(2005)reportthathigherextroversionisrelatedtogreaterrisktolerance[68];McCraeandCosta (1997) link personality to tolerance of uncertainty, innovation andwillingness tothink outside the box[69]; Kowert, 1997) links personality to adventurousness,imagination, the search for newexperiences and actively seekingout risk[70]. Buildingfrom these foundations of well validated assessment practices, more specializedassessmentshavebeendeveloped,includingassessmentofRiskType[71]

CHAPTER-2LiteratureReview2.1.WhatismeantbyRisks?

Wedefineriskasapossibilityofloss,thelossitself,oranycharacteristic,object,oractionthatisassociatedwiththatpossibility.Inotherwords,weareprimarilyconcernedwiththenegativeconsequencesofpotentialfutureevents.Therearetwoimportantpointstomakeregarding this definition. First, it is a different definition from the one often used infinance and economics, where risk is essentially defined as a volatility of a financialinstrumentovertime[76,77].

Second,eventhoughourdefinitionemphasizesthenegativeconsequences,ourapproachalso includes and supports themodeling of positive consequences of future events, i.e.,riskmanagementcanalsobeseenasawayof recognizingandmanagingopportunities.Ourdefinitionofriskalsoextendsthetraditionalviewofriskbyincludingexplicitlinkstoexpectations–orgoals–andstakeholders,asshowninFigure1.Riskischaracterizedby

aprobabilityandlossassociatedwithit.Thelossesaredefinedbywhattheexpectationsor goals are, and they, in turn, are defined by the stakeholders thatmay have differentexpectations. Thus, definition and quantification of a risk requires that the expectationsandstakeholdersareknown.

Fig.1:DefinitionofriskintheRiskitmethod[75]

The termriskmanagementhasbeenused in twomeanings in thesoftwaremanagementliterature.Ononehandithasbeenusedtorefertothedisciplinethatthatstudieshowtoidentify,address,andeliminaterisks[78],ontheotherhandithasbeenreferredtoastheactivityorprocessthatattemptstoidentifywhatcouldgowronginaprojectandtakingsteps toavoidsuchproblems inadvance[79,80,81] In thiswork,weuse the termriskmanagementtorefertoactivitiesthataretakentoidentify,analyzeandcontrolrisks.Weuse the term risk management process to refer to a systematic and explicit riskmanagementactivity.Theriskmanagementprocesscanbeseenashavingtheinputsandoutputs presented in Figure 2: the input of the process consists of project contextinformation,goals,andplansfortheproject.Riskmanagementmethodsandtoolsareusedto support riskmanagement, and theprocessdelivers twooutputs: understandingof therisksandriskcontrollingactions.

Fig.2:Riskmanagementprocessinputsandoutputs[75]

HistoryofRisk

Itisobviousthatpeoplehavebeendealingwithrisksonanintuitivelevelaslongasthemankind has existed: hunting and farming have involved risks since the beginning oftimes.Peoplehavealsobeenplayinggamesofchanceforpossibleseveral thousandsofyears[82],eventhoughtheconceptsofchanceandprobabilityhavenotbeenknown,oratleast not well understood [83]. Conscious and more analytical approach risk is still arecentphenomenon inourhistory.The term riskoriginates through Italian fromaLatinword resceare,meaning “to cut off. It is believed that thewordwas originally used bysailors to refer to danger [84].However, the notion of risk and probabilities were notcommonlyused,until the fundamentalconcepts of riskwere gradually discovered from17thcenturyonwards.Sambursky[85]andBernstein[86]offeratheorytoexplainthis:inancientGreeceandlaterintheWesternculturetheuncertaineventswereconsideredtobe“acts ofGod” or results of faith. Estimating, calculating ormanaging such events wasconsideredtobebeyondwhatmortalsshouldorcoulddo.Instead,manwastotakewhatfaith brought along. The modern risk management practice still relies on severalfundamental concepts thatwere introduced since the 17th century. First, the theory ofprobabilitywas createdbyBlaisePascal andPierre deFermat, prompted to do so by anoblemanwhowanted to find a solution to an old gambling puzzle [84,87]. However,severalearlierauthors,includingGerolamoCardanoandGalileoGalileiseemtohaveputforwardsomebasicconceptsonprobability evenearlier [83]. The theory of probability

contains the axioms and theorems that establish the mathematical basis for calculatingprobabilities.Theaxiomsoftheprobabilitytheoryarelistedbelow[88]:

AxiomI:ToeveryrandomeventA therecorrespondsacertainnumberP(A), called theprobabilityofA,whichsatisfiestheinequality0≤P(A)≤1

AxiomII:Theprobabilityofsureeventequalsone,i.e.,P(E)=1

AxiomIII:Theprobabilityofthealternativeofafiniteordenumerablenumberofpairwiseexclusiveeventsequalsthesumoftheprobabilitiesoftheseevents.

Whiletheprobabilitytheoryprovidedthemathematicalbasisforperformingcalculationson probabilities, until the 20th century it was only used in calculating games or intheoreticalmathematical discussions. The practical application of the probability theorywasrare.Second,JacobBernoulliestablishedtheprincipleofstatisticalsamplingin1713(Bernstein1996;Struik1987).This ideaessentially allowed theuseof samples to infergeneralconclusions–orprobabilities–toalargerpopulation.Third,anEnglishministerThomasBayes defined the theorem carrying his name (Bernstein 1996), supporting thecalculation of probabilities and conditional probabilities inmany practical applications.Fourth,thephenomenonofnormaldistributionwasdiscoveredbydeMoivrein1725.Thenormal curve helps explain the variance and distribution of many natural phenomena.Fifth,FrancisGalton’sintroductionoftheregressiontothemeanhelpedunderstandhowthedatabehavesinvariousdistributionsandhowitcanbeinterpreted(Bernstein1996).

Riskmanagementhasbeenaroundforsometime.Theword“risk”stemsfromtheItalianverb risicare”. The science of risk management was developed back in the sixteenthcenturyduringtheRenaissance,aperiodofdiscovery.Thetheoryofprobability,whichisthecoreof riskmanagement,wasdeveloped tohelpbetterestimatepeople’schances ingames. What is a risk? This question can best be answered using an example fromeveryday life. All cigarette packs are marked with warnings such as “Smoking isdangeroustoyourhealth”or“Smokingcausescancer”.Ifoneanalysesthesestatements,oneseesthat theydescribeacause(smoking)ofaproblematicsituation(canceroccurs)anditsimpacts(shorteningoflife).Therearemanydefinitionsoftheterm“risk”butnogenerallyacceptedone.Alldefinitionsimplicitly include twocharacteristics:uncertainty(an event may or may not occur) and loss (an event has undesired effects). This isdemonstratedbythefollowingexamples:

·Used in nouns, theword “risk” indicates that somebody or something is subject to adangerorcertaindangers;

·Riskisthepotentialfortheoccurrenceofundesired,negativeconsequencesofanevent[Rowe88];

· Risk is the possibility of suffering losses, damage, disadvantages or destruction[Webs81].

BasedonWebster’sdescriptionof“risk”,weshallusethefollowingdefinition:

Risk is thepossibilityofsuffering lossesdue toanevent thatwillquiteprobablyoccur.According to [Kont97], a risk can be illustrated using “risk scenarios” containing thefollowingelements:

·Ariskfactorissomethingthaninfluencestheprobabilityofanegativeeventoccurring;

·A risk event is the occurrence of a negative incident or the discovery of informationrevealingnegativecircumstances;

·Ariskreactionisanactionwhichcanbecarriedoutwhenariskeventoccurs;and

·Ariskeffectistheimpactofariskeventontheproject.

A risk scenario is a chain consisting of a risk factor, risk event, risk reaction and riskeffects.TheexamplegiveninFigure1includesthefollowingriskscenario:“Thedatabasereleaseisstillinthebeta-testphase.Problemscouldoccurwiththedatabaseintegration.Ifso,adatabaseexpertmighthavetobecalledin.ThiswouldcauseadditionalprojectcoststotallingDM20,000.”[5]

RiskManagementinSoftwareEngineering

Withintherealmofsystemsandsoftware,riskmanagementwasinitiallyaddressedbythemanagement information systems (MIS) community. Nolan[89,90] and McFarlan [91]proposedmodels for managing the information technology and project portfolio in the1970’s, Alter and Ginzberg proposed that analysis of risk factors can help developerssucceed[92],Davisproposedamodelforselectingadevelopmentapproachbasedontheuncertainties in requirements [93] and Saarinen et al. have developed more elaboratemodels to support project portfolio management [94]. Despite these efforts, risks insoftware development were not addressed in any detail until late 1980’s, whenBoehm[95,78]proposedandsynthesizedmoredetailedapproachesforriskmanagement.HisworkwascomplementedbyCharette[79]andsoftwareengineeringriskmanagementis now an established area within software engineering community. The SoftwareEngineeringInstituteandannualsoftwareriskmanagementconferencesactedasthemain

forumtoshareexperiencesandresultsbetweenpractitionersandresearchers[96,97,98,99].

More recent advances in software risk management have produced well-documentedapproaches for risk management [51, 81, 100] several categories of risks have beenproposed [101, 102, 103, 78], quantitative approaches for risk management have beenproposedandused[104,105,106],andthereareseveralsoftwaretoolsavailableforriskmanagement.

Despitetherecentadvancesinriskmanagementandtheobviousindustryinterestinit,itseems that only a minority of organizations are using specific risk managementapproaches actively. The U.S. defense sector has been addressing risk managementsystematicallysinceearly1980s[107,108,109,110].Thegovernmenthadsetupaninternaltrainingprogramthatincludededucationonriskestimationandanalysistechniques.TheU.S.Army,infact,hadsetupasystematicriskassessmentrequirementalready in1981,programmanagerswererequiredtoestimatethecostofriskusingadefinedmethodcalledTRACE[110].

TRACErequiredsystematicstepstobefollowedinassessingprojectrisksandproposedasetoftechniquesforthesesteps.Asaresult,projectswereallocatedaspecificfundthatcouldbeusedifrisksrealized.Itseemsthatthesefundswerenotusedforriskprevention,however.Thenotionofriskbudgetmaybeausefulideaforcommercialprojectsaswell,butitshouldbeprimarilyusedforriskprevention.However,theirprimaryfocushasbeenintheplanningandbudgetingstageofdefenceprograms,notinday-to-daymanagementofsoftwareprojectsand,consequently,someprogramsdonotmanagerisksexplicitlyatall[111].

Industrial reports on software risk management are relatively rare with some notableexceptions [112,113,114,105,103,115, 116,117]. None of these reports has been able toprovide concrete, quantifiable data about the benefits of risk management methods,although theydoprovide indications that somebenefits exist.BarryBoehm’swork hasbeenthemainfoundationformostoftheriskmanagementworkinsoftwareengineering[118, 119, 95, 78, 112, 119].Hismain contributions have been in establishing the riskmanagementasanimportantfieldofstudyinsoftwaremanagement,introductionofsomekeymeasures for risk, and synthesizing a set of techniques into a single framework forrisk management. Boehm’s spiral life cycle model was the first life cycle model toincorporate riskmanagement explicitly in it (Boehm 1988) andmany recent papers on

software life cycles have incorporated similar notions of risk in them. In his riskmanagement tutorial (Boehm1989)Boehm presentedmore detailed account of his riskmanagementapproach.Boehm’sriskmanagementapproachreliesonthequantificationofrisk.Heusedthetermriskexposureasameasureofrisk:

RiskExposure=Probability(Outcome)*Loss(Outcome)

Theriskexposureisessentiallytheexpectedvalueoftherisk(event).Expectedvalueisawell-established way of calculating uncertain events. The use of expected value as ameasureofriskhasseveralimportantbenefits[120]:ithasasolidtheoreticalfoundation,itcanbeusedwithdifferentmeasurementunitsandscales,anditallowsaggregationanddisaggregationofresults.

Table1:Boehm’sriskmanagementmodel[75]

SEI’s Software Risk Evaluationmethod has been developed to support systematic riskevaluation[121].Themethodhasbeenalsoextendedtosupportteamsinriskmanagement[80] and SEI has started collecting their assessment results into a database for furtheranalysisofidentifiedrisks(Monarchetal.1996).SEI’smethodisstructuredaroundasetofcontinuoustasksthatguidetheriskmanagementprocess:

Identify:ThemethodreliesonSEI’srisktaxonomytoidentifypotentialriskareas(see

Table2).

Analyze: Transforming data from the identified risks into decision-makinginformation. The SRE approach recommends using two alternative, table-basedapproachesforrankingrisks.

Plan:Planriskmitigation,i.e.,definesandrankactionstomitigaterisks,prioritizeactions,andintegratingthemintoanexecutableriskmanagementplan.

Track:Monitoringthestatusofrisksandtheirmitigationactionsalongwiththeuseofmetricsandtriggeringevents.

Control:Correctingthedeviationsfromplannedriskmitigationactionsbyusingexistingprogramorprojectmanagementcontrolfunctions.

Communicate:Exchangingriskmanagementinformationamongthefunctionsandatalllevelsoftheorganization.

Figure3:SEI’sriskmanagementcycle[75]

Table2:SEI’srisktaxonomy[75]

Althoughthetechnologyofsoftwareandsoftwaredevelopmenthaschangeddramatically,and the number of software packages acquired by organizations has increasedsignificantly,problemswiththeimplementationofinformationsystemsremainscommon.Inthelateseventiesandearlyeightiestheimplementationofamanagementinformationsystemwasconsideredfraughtwithuncertainty[122]anditwastheexceptionratherthantheruleforanorganizationtodevelopaninformationsystemwithinbudgetandaccordingtoschedule[123].

Althoughmodern software practices [123] have benefited the management of softwaredevelopmentoverthelast20years,thefailurerateofnewimplementationremainshigh.Identifyingriskfactorsandprobabilitiesassociatedwiththerisks[125,122,and124]hasbeen viewed as a step to reduce risk. Quantitative and qualitative models have beendeveloped [126,124] tomeasure themagnitude of risks. Riskmanagement of softwareprojectshasbeenthefocusofmuchresearchoverthelast20years.Riskassessmentand

risk control [125] are the two main steps in managing project risk for softwaredevelopment.

Risk assessment involves risk identification, risk analysis and risk prioritization. Riskcontrol involves risk management planning, risk resolution and risk monitoring.Assignmentofprobabilities[125,126]isusedtoevaluatethelikelihoodoftheoccurrenceofhazards.Combiningestimatesoflossmagnitudewithfailureprobabilities[125,126]isthe usual way of evaluating risk situations. Several factors have been identified [125,122,124]thatthreatensuccessfulsoftwareimplementation.Boehmgivestenfactors,AlterandGinzberg identify eight factors and Barki et al., conducted a literature review thatidentifiedthirty-fiveriskfactors.Forinstance, lackofmanagementcommitmentisoftencitedforprojectfailure[127].

Softwaredevelopmentmethodologiesattempttoreduceriskbygatheringinformationandusing structured processes. The implicit assumption is that by following a goodmethodologyandidentifyingriskfactors,softwareriskisreducedenoughtoavoidfailure.However,acontinuousstreamofsoftwarefailuresmaybeahintthattherearerisksthatcannotbeovercomebytraditionalapproachestosoftwaredevelopment.Onekeyfactoristhe behavior of decision makers using any methodology. Markus (1983) showed theimportanceofpowerandpoliticsonsoftwaresuccess,demonstratinghowanindividual’smotivation can have a dramatic impact on the success of a systems implementation.Introducingabetter softwaredevelopmentmethodology into sucha situationwouldnotlikely have changed the results. By contrast, changes in personnel motivation had onoverwhelmingimpactonsuccess[1].

Project failures are the result of the multiplicity of risks inherent in software projectenvironment.Softwaredevelopmentprojectsarecollectionsoflargerprogramswithmanyinteractions and dependencies. It involves a creation of something that has never beendonebeforealthough thedevelopmentprocessesare similaramongother projects.As aresult, software development projects have a dismal track-record of cost and scheduleoverrunsandqualityandusabilityproblems.JiangandKlein(1999)finddifferenttypesofriskswillaffectbudget,usersatisfactions,andsystemperformance.Otherstudiesindicatethat15to35%ofallsoftwareprojectsarecancelledoutright,andtheremainingprojectssufferfromscheduleslippage,costoverruns,orfailuretomeettheirprojectgoals[129].

Time-to-market is the most critical factor for consumer in developing commercialsoftware products. However the project success is difficult to predict because projectscope ischangedbycontinuousmarket requirementsand resourcesareconstantlybeing

reallocatedtoaccommodatelatestmarketconditions.Projectsforspecificcustomersalsohave a large degree of uncertainty for requirements due to the customized technicalattributes.As a result, software development engineers have high turnover rates amongsoftware development firms. For example, software managers in India perceivedpersonnelturnoverastheirbiggestsourceofrisk[128].

Many software projects and programs involve multiple entities such as companies,divisions,etc., thatmayhave certain interests.There is often a feelingof disconnectionbetweensoftwaredevelopersandtheirmanagement,eachbelievingthattheothersareoutoftouchwithrealityresultinginmisunderstandingandlackoftrust.Researchshowsthat45%ofallthecausesofdelayedsoftwaredeliverablesarerelatedtoorganizationalissues[130].

Softwarerisksandriskmanagementperceptions

Current perceptions about risk management from majority of software projectorganizations contributes to the lack of project stability in addition to the inherentchallengesposedbythenatureofsoftwareprojects.KwakandIbbs(2000)identifiedriskmanagement as the least practiced discipline among different project managementknowledgeareas.BoehmandDeMarco (1997)mentioned that “our culture has evolvedsuchthatowninguptorisksisoftenconfusedwithdefeatism”.Inmanyorganizations,thetendency to ‘shoot the messenger’ often discourages people from bringing imminentproblemstotheattentionofmanagement.Thisattitudeistheresultofamisunderstandingofriskmanagement.Boehm(1991) identified10softwarerisk items tobeaddressedbysoftwaredevelopmentprojects:

Personnelshortfalls

Unrealisticschedulesandbudgets

Developingthewrongfunctionsandproperties

Developingthewronguserinterface

Goldplating(addingmorefunctionality/featuresthanisnecessary)

Continuingstreamofrequirementschanges

Shortfallsinexternallyfurnishedcomponents

Shortfallsinexternallyperformedtasks

Real-timeperformanceshortfalls

Strainingcomputer-sciencecapabilities.

Jones (1998) further presented three key software risk factors and concerns of bothexecutivesandsoftwaremanagers.

Risksassociatedwithinaccurateestimatingandscheduleplanning

Risksassociatedwithincorrectandoptimisticstatusreporting

Risksassociatedwithexternalpressures,whichdamagesoftwareprojects.

However, most software developers and project managers perceive risk managementprocessesandactivitiesas extrawork and expense.Riskmanagementprocesses are thefirstthingtoberemovedfromtheprojectactivitieswhentheprojectscheduleslips.Thefree-spiritedcultureinmanysoftwaredevelopmentfirmsisinconflictwiththeamountofcontroloften required todevelopcomplex software systems in a disciplinedway. Jones(2001)mentioned“itisapeculiarityofITthatverycomplexsystemscanbebuiltwithavery low level of control by clever, driven people”. Many software developmentpractitionersunderstandriskmanagementandcontrolasinhibitingcreativity[2].

RISKCLASSIFICATION

The primary purpose of classifying risk is to get a collective viewpoint on a group offactors,whichwillhelpthemanagerstoidentifythegroupthatcontributesthemaximumrisk.Ascientificwayofapproachingrisksistoclassifythembasedonriskattributes.Riskclassificationisaneconomicalwayofanalyzingrisksandtheircausesbygroupingsimilarrisks together into classes [31]. Software risks can be internal or external. The internalriskscomefromriskfactorswithintheorganization.Theexternalriskscomefromoutofthe organization and aredifficult to control. Software risks can be grouped into projectrisks,processrisks,andproductrisks.Thisclassificationsystemcanbeeasilyappliedtointernalrisks[131,132,133].

Riskscanbedividedintothreegeneraltypes[134]:project,business,andtechnicalrisks.Also,softwaredevelopmentriskcanbeclassifiedintothreeclasses:productengineering,developmentenvironmentandprogramconstraint.Another typeof software risk canbegroupedintoschedulingrisksandqualityrisks.Inaddition,riskscanbecategorizedintoperformance risks, cost risks support risksand schedule risks [33]. In general, there aremanyrisksinthesoftwareengineering.Itisverydifficultorimpossibletoidentifyallofthem.

A.ClassifyingSoftwareRisks

In this section softwareengineeringproject risksarecategorized. Software project riskscan affect requirements,scheduling, cost, quality and business. Therefore, classificationon the basis of these groups can be done.Tables 3 to 7 represent these classifications.Theserisksaregottenthroughstudiesandexperiencesinprojects.

Table3:SOFTWAREREQUIREMENTRISKS[135]

Table4:SOFTWARECOSTRISKS[135]

Table5:SOFTWARESCHEDULINGRISKS[135]

Table6:SOFTWAREBUSINESSRISKS[135]

Table6:SOFTWAREQUALITYRISKS

Table7:SOFTWAREQUALITYRISKS[135]

RiskManagementServiceProviders-OrganizationsandcorporationsofferingSoftwareRiskManagementproductsandservices.

C/S Solutions, Inc. (C/SSI) C/SSI produces integrated analytical tools for cost,schedule, and Risk Management. Their tools are specifically designed to engageIntegratedProductDevelopment (IPD) teammembersand/orCostAccountManagers(CAMs)inproactivecost,scheduleandRiskManagementofcomplexprograms.

GRafP Technologies Inc. GRafP develops software packages which can be used to

identify threats, and to analyze and manage the risks to which an entity (i.e.organization, project, individual, etc.) is exposed. Two such products areX:PRIMERand S:PRIMER. Services offered as part of that mission include risk ratings andassessments,processassessments,remedialactionplanning,andtraining.

KLCI-KLCIhelpssoftwaredevelopmentorganizationsacceleratecompletionoftheirprojects. Their methodologies include: Software Risk Management, software projectmanagement,andcriticalpathmanagement.

R.S.Pressman&Associates,Inc.-R.S.Pressmanprovidesservicesandproductsthathelpanorganizationtoimproveitssoftwareengineeringpractices.Thecompanyoffersvideo training products, consulting services, and Software Process Improvementproducts.TheirWWWsiteprovidesaccess toacomprehensivecollectionofsoftwareengineeringresources.

Risk Services & Technology (RST) - RST offers services in the following areas:ProjectRiskManagement,DoD(Directive5000.2-R,Clinger-CohenAct),EarnedValueManagementSystems,andRiskManagementSoftwareProducts.

SEI Continuous Risk Management Service (CRM) The CRM Service from theSoftwareEngineeringInstitute(SEI),incorporatesallthattheSEIhaslearnedfromitsresearchandworkingwithmorethan50clientsinthefieldofRiskManagement.ThisservicetailorstheSEIContinuousRiskManagementprocesses,methods,andtoolstoaspecificprojectororganization.TheserviceintegratesandadaptsthepracticeofCRM,as defined in the Continuous Risk Management Guidebook, with current programmanagement practices. The cornerstone of this service is the Risk Clinic; an on-siteworkshopthatbuildsatailoredRiskManagementPracticefortheprojectandaplanforimplementingthepractice.

Software Risk Evaluation Service (SRE), an SEI ServiceThe SEI Software RiskEvaluation (SRE) Service is a diagnostic and decision making tool that enables theidentification, analysis, tracking,mitigation, and communication of risks in software-intensiveprograms.AnSRE isused to identifyandcategorize specificprogramrisksemanating from product, process, management, resources, and constraints. Theprogram’s own personnel participate in the identification, analysis, andmitigation ofrisksfacingtheirowndevelopmenteffort.

RiskManagementToolsandMethods-Developers,catalogs,anddemonstrationsof

SoftwareRiskManagementtoolsandmethods.

C/S Solutions, Inc. (C/SSI) C/SSI produces integrated analytical tools for cost,schedule, and Risk Management. Their tools are specifically designed to engageIntegratedProductDevelopment (IPD) teammembersand/orCostAccountManagers(CAMs)inproactivecost,scheduleandRiskManagementofcomplexprograms.

DefenseAcquisitionDeskbook-RiskManagementSoftwareToolsThisportionoftheDefense Acquisition Deskbook Catalog provides descriptions of software tools thatassistProgramManagersinRiskManagementactivities.

GalorathInc.(alsoknownasGASEER�Technologies)providesacomprehensiveset of decision-support and production optimization tools. Consulting and supportservices are available for these tools. The tools help manage product design andmanufacturing operations, driving out costs and building in quality. The tools derivecost,schedule,laborandmaterialsestimatesbyassessingtheinteractionandimpactofproduct,organizationalandevenoperationalvariables.

RISKMAN Risk Management Expert System Riskman is intended for use bysoftware engineers with minimal software project planning experience who areinterestedinplanningasmallteamsoftwaredevelopmentproject.RiskmanwaswritteninQuntusPrologandshouldbeuseableonanyversionofProlog.

RiskRadar,anSPMNproductRiskRadarisaRiskManagementdatabasefromtheSoftwareProgramManagersNetwork(SPMN).Itspurposeistohelpprojectmanagersidentify, prioritize, and communicate project risks in a flexible and easy-to-use form.Risk Radar provides standard database functions to add and delete risks, as well asspecialized functions for prioritizing and retiring project risks. Each risk can have auser-definedRiskManagementplanandalogofhistoricalevents.

RiskTrak Home page for Risk Services& Technology and RiskTrak, their softwaremanagement tool.RiskTrak isRiskManagement groupware that allows you to view,analyze,communicate,reportandmanagerisk(cost,scheduleandtechnical)throughoutthe duration of your projects and programs. RiskTrak is designed to help businessesmeetnewstandardsonRiskManagementsuchas:Clinger-CohenAct(ITMRA),DoDDirective 5000.2-R, CAIV and OMB Circular A-11. RiskTrak supports BestCommercial Practices and is designed to be integrated with any Earned ValueManagementSystem(EVMS).

SoftwareInsightToolforInternalRiskMitigationReviewsandCIOAssessments,

V3.2August1999Thisdocumentpresentsacomprehensivesetofquestionsdesignedto assist the Program Manager in evaluating a their program against Statutory andRegulatory requirements, as well as software acquisitionBest Practices. Use of thisdocumentwill aid in the reductionof program risk andhelp ensure a higher level ofqualitysoftware.

Turbo Streamliner Developed by the Navy Acquisition Reform Office, TurboStreamliner provides the tools and references to assist in reviewing or developingacquisition solicitation packages. This tool describes how to implement acquisitionreform policies in preparing Requests for Proposal (RFPs) and other contractualvehicles. Turbo Streamliner covers the following topics: RFP Review Checklist,ReportingMetrics,LessonsLearned,AcquisitionReformPrinciples,RiskManagement,andPost-AwardBenchmarking.

X:PRIMERandS:PRIMERThesssoftwaretoolareforisolatingprocessrelatedrisksin a project or anorganization.Theyusequestionnaires on theSoftwareEngineeringInstitute’s(SEI)CapabilityMaturityModel(CMM)andSEIRiskTaxonomy.

2.2.EvolutionofRiskmanagement

Thelastfewdecades–especiallytheendof20thcentury,andthebeginningof21stcentury–hasshownanincreaseintheinterestinautomationofdifferentactivities.Automationisdependent in its core on sound functional software. The complexity of softwaredevelopment has increased significantly over the years. Articles showing the failure ofprojects in the software industry are not surprising. Standish Group reports (StandishGroup,1994) show that about53%ofprojectsget completed,but theydonotmeet thecost,andschedulerequirements,andabout31%arecanceledbeforethecompletionoftheprojects.Thesefailurereportsaresignificantlyalarming.

McManus(2004)identifiedthat65%oftheprojectfailuresareaccountedbymanagementissues, and 35% by technical issues. Managerial issues include problems with projectstructure,projectresources,planningmethodologies,customerbuy-in,andinadequateriskmanagement. Technical issues include poor software design, non-adherence to softwarerequirements, improper technical reviews, and incorrect development, and testingmethodologies(McManus,2004).

It is conjectured that themanagement of risks can lead to the success of projects.Riskmanagementhasbeenpopularinnon-softwaredomainsforseveraldecades.However,itis

primarily in the last few years that risk management in software domains has becomepopular.However,atpresentriskmanagementinsoftwareisadevelopingdiscipline–itispoorlyunderstood,andpracticed.Comparedtotheriskmanagementliteratureavailableinother disciplines (e.g., insurance, and manufacturing), the volume of risk managementliterature available in software is scarce. In this article, we attempt to review thefundamentalsofsoftwareriskmanagement,thedifferentpopularriskmanagementprocessmodels, and the recent research trends in the area of software engineering riskmanagement.

Software engineering risk management activities are conducted at the project level,process level,andproduct level.However, in thisarticle,wefocusprimarilyonproject-level,andprocess-levelriskmanagement.

Practitioners and researchers poorly understand the area of software engineering riskmanagement, even though themanagementof risks in softwareprojects is an importantissue,whichcansavemillionsofdollarsintheprojects.Wealsorealizedthescarcityofreviewarticlesinthisarea.Thispromptedustoexhaustivelyreviewtheworkdoneinthisarea, andprepare thisarticledescribing the important fundamental concepts in thearea,thedifferentimportantprocessmodelsforriskmanagementthathavebecomepopularinthelast1.5decades,andtherecentresearchadvancesthathavetakenplaceinthelastfewyears.

Thedictionarymeaningof“risk”is“thepossibilityoflossorinjury”(Source:Merriam-Webster Dictionary). The term risk has its Etymological origin in the Latin word“resceare”, which means “to cut-off”. It has evolved since then as the French word“risqué”,andtheItalianword“risco”.

Thetermriskisuseduniversallyindifferentcontextualdomains.Forexample,itisusedin the financial sector to mean the possibility of incurring financial loss, and in themedical sector to mean the possibility of physiological loss to life. In the “software”world, risk is an important issue often referring to the sources of danger to softwaredevelopment,acquisition,procurement,ormaintenance.

One of the important considerations challenging any riskmanagement researcher is thedefinitionofrisk.Inotherwords,beforeproposinganyriskmanagementframeworkoneneeds to specify/quantify the ‘dimensions’ of risks. This is because it is a challenge tounanimouslyagreeon thedefinitionof risk.Thereare several formaldefinitionsof riskavailableinliterature,fewofwhicharepresentedbelow.

“A possible future event that, if it occurs, will lead to an undesirable outcome”(LeishmanandVanBuren,2003).

“Riskisacombinationofanabnormaleventorfailure,andtheconsequencesofthateventorfailuretoasystem’soperators,users,orenvironment.Ariskcanrangefromcatastrophic (loss of an entire system, loss of life, or permanent disability) tonegligible(nosystemdamageorinjury)”[136].

“Risk refers to a possibility of loss, the loss itself, or any characteristic, object, oractionthatisassociatedwiththatpossibility”[137].

RISKMANAGEMENT

Simply put, riskmanagement is away tomanage risks. In otherwords, it concerns allactivities that areperformed to reduce theuncertainties associatedwithcertain tasks,orevents. In the context of projects, riskmanagement reduces the impacts of undesirableevents on a project. Risk management in any project requires undertaking decision-makingactivities.

ORIGINOFRISKMANAGEMENT

Risk management has its roots in probability theory, and decision making underuncertainty.Threewell-knowntheoriesintheseareas–expectedutilitytheory[138,139],theoryofboundedrationality[140],andprospecttheory[141,142]–wereofthegreatestinfluence.These theoriesmaybeconsideredasdisciplinesby themselves.Therefore, toputourdiscussionsonriskmanagementincontext,webrieflystatebelowonlywhateachofthesetheoriespropose.

In brief, the expected utility theory discusses how people make choices from differentalternatives,basedontheirexpectedutility.Thetheoryofboundedrationalitystatesthatfor real life events, the outcomes, and their associated probabilities are very limitedlyunderstoodbypeople tomake the requireddecisions tomaximize their expectedutility.Therefore, people have a tendency to set up targets of aspiration in life by eliminatingalternatives from thedifferentoptions theyhave.This theory isuseful formodeling thebehaviorofprojectmanagementpersonnelinchargeofriskmanagement.Prospecttheory,whichhasitsorigininPsychology,helpstomodelhowtheperceptionsofhumanbeingsinfluence their choices from the given options. It, thus, helps for understanding, andestimating the utility losses of different alternatives while analyzing risks in risk

management.

Theworld is runs on software. Practically all fields of human activity are increasinglydependent on software to support, operate, or control machinery, information flows,records, or processes. An increasing number of products contain embedded software,peoplewhodesignthemusesoftwaretoplanandengineertheproduct,themanufacturingprocessisplannedandcontrolledbysoftware,thelogisticschainthatdeliverstheproductto the customer is dependent on software and databases, and, finally, the monetarytransaction for the product takes place through the software and databases of financialinstitutions.Ourabilitytodevelopandrunsoftwarestronglyinfluenceshow,oractually,whether the societyfunctions.Not only has the role of software increased substantiallyoverpastdecades, thesoftwaredevelopment industryhasgrownintoa largesegmentofthe economy, theworld-wide value of information and communication sector has beenestimatedtobe320billionEuros(Anon.1998b).

IntheU.S.,thegrowthrateofsoftwareindustryhasbeen2.5timesthegrowthrateoftheeconomy as a whole (Nukari & Forsell 1999), and the information technology sectoraccountsforaquarteroftheeconomicgrowthintheU.S.(Anon.1998a).Softwareisbeingdeveloped inprojects thatemploy thousandsofpeopleacrosscompanies,countries,andtimezones.Furthermore,theimportanceofsoftwareislikelytocontinuetoincrease.TheInternetaloneisanenvironmentthatoperatesonsoftwareandacceleratesthedistributionand use of software, the so called new economy will further enhance the businessopportunitiesbasedon software (Shapiro&Varian1998), and intelligent appliances forindividualswillmakesoftwareevenmorepresentandcommoninthesociety.

Softwareprojectshaveturnedout tobedifficult tomanagewithintimeandbudget.Thesoftwareindustryhasalongtrackrecordofoverrunbudgets,misseddeadlinesandlackingfunctionality, reports of such problems have been presented over several decades(McFarlan1974;Rothfeder1988;Charette1989;Flowers1996;Glass1997).Infact,theterm“softwarecrisis”hasbeenusedtodescribethestateof thepractice in the industry:projects continually fail to meet the increasing demands for better quality, higherproductivity, and greater functionality. While there are undoubtedly many “runaway”projects,itisquestionablewhetherthewordcrisisis,still,theappropriatetermtodescribethestateofsoftwareengineeringpractice.Onecanarguethatthereporteddisasterprojectsrepresent extreme cases and the large mass of successful or nearly successful projectssimplydonotpassthepublishingthreshold(Glass1998).Nevertheless,thelargevolumeof software development and at least the very big potential for disasters call for

improvementsinthewaysoftwaredevelopmentisplannedandmanaged.

Of the many engineering disciplines, software engineering is more prone to risks thanmany other areas. In software projects, processes and requirements evolve more,complexityofproducts ishigher,and thereareahighernumberofpotential riskfactorsthaninmanyotherdisciplines(Fairley1989).Thisispartiallyduetotheinherentnatureofsoftware development, in principle; all projects aremore unique than those of otherdisciplines: identical software can be copied at no cost whereas similar physicalcomponentsstillneedtobemanufactured.Thisuniquenessmakesitmoredifficulttoplan,modelandpredicttheprogressofasoftwareproject.

BothFairley(Fairley1989)andBrooks(Brooksjr.1987)havehighlightedthecomplexityofthesoftwareengineeringasoneofitsspecificcharacteristics.Whileabstractionisoftenusedtodealwiththesizeofsystemsandtosomedegreewithcomplexity,abstractioncanonly provide partial views to the complexity of a system, it cannot abolish complexity.Complexity is a typical characteristic of software and developing complex systems isdifficultanddealingwiththiscomplexitymakesuspronetomistakes.

Brooks (Brooks jr. 1987) also pointed out that software engineering is a man-madedisciplinethatdoesnothaveanyuniversalconstantsor“naturallaws”thatwouldprovideacleartheoreticalplatformoranchorpointsforthediscipline.Manyofthestandardsandpracticesinsoftwareengineeringhavebeenestablishedoragreeduponbydefactomarketdomination or by negotiation process by key players in the industry.As a result, thesestandardsand“laws”arenotnecessarilycompatiblewitheachotherorconstant.Softwareislinkedtomanyotherhumanandorganizationalsystemsthatevolveovertime(Brooksjr.1987).

The interfaces, required functionality, and system architecture are all designed andprogrammedexplicitlyforagivenenvironment.Astheseothersystemsevolve,softwarealso must also evolve, even during a development project. The changing environmentcreatesadditionaluncertainelementsinasoftwareproject,againincreasingthepotentialfor risks to surface and occur. The invisibility of software (Brooks jr. 1987) alsocontributes to the risks in software projects. Invisibility makes it harder for people tounderstandalltherelationshipsbetweendifferentcomponentsandaspectsofsoftware.

Softwareisalsoayoungfieldandthecumulativeexperienceofthecommunityisfarlessthanalmostinanyotherengineeringarea.Whilesoftwareprogramshavebeenwritteninindustrialscalesincethelate1950’s,thesoftwareengineeringdisciplinebegantoemergeinthelate1960’sandeventodaythesoftwareengineeringcommunitydebateswhetherit

hastrulybecomeanengineeringdiscipline(Basili1996;Pfleeger1997;Tichyetal.1995;Tichy1998;Zelkowitz&Wallace1998).The lackof empirical,historicalmeasurementdataalsomakesitdifficulttounderstandandmanagethesoftwareengineeringprocess.

Software engineering is a field with very rapid technology development cycles. Thehardware platforms, systems standards, and development tools are under a constantchange(Selig1993)andnewtechnologyisadoptedwithlessrigorousevaluationthaninother fields (Fenton et al. 1994; Tichy 1998; Zelkowitz & Wallace 1998). It is notuncommonthatthetechnologicalplatformischangedinamiddleofaproject.Eachnewtechnologywillbringalongnew,possiblyunknownriskstoaprojectanditmayinvalidatethe previously accumulated risk knowledge. Traditional engineering fields benefit fromseveral engineering cycles that gradually perfect the designs and eliminate potentialproblems (Petroski 1985; Fortune & Peters 1995). This is more difficult in softwaredevelopmentasdesignsarelessoftenreusedandsubjectedtosuchrepeatedreviews.Userexpectationsfromsoftwarearealsocontinuouslyincreasingaspeopleareusingdifferentapplications and are exposed to new opportunities offered by software. These growingexpectationsdecreasethestabilityofasoftwareproject,againopeningadoorforpotentialrisks.

Finally, the software industry has recently become truly international as far as thecompetitionisconcerned.Evenasmallsoftwarecompanymustcompetewithalternativesolutions that may be offered by international industry giants that have much largerdevelopment resources. The Internet has also opened competition much wider: manycustomers can easily access and consider competing alternatives from geographicallydistantlocations.Theincreasedcompetitionencourages,ifnotforce,softwarecompaniesto take bigger leaps in their software development, leading to greater risk taking.However, some surveys indicate that the industrial practice of risk management isinformal and infrequent: according to Ropponen’s survey, 75% of the surveyed projectmanagersdidnotusemethodstoidentify,evaluate,orcontrolrisks(Ropponen1993).

ThelimitedsurveydatafromaworkshopbyBasiliandToriisupportsthis:only20%ofrespondentsclaimed touse riskmanagement techniques“extensively”while40%statedthattheyarenotusing“anyriskmanagementtechniquesorapproaches”(Kontio1995a).Clearly,theindustrypracticeinapplyingriskmanagementmethodsseemstobelessthanthesignificanceof theproblemwouldsuggest.Webelieve there are several factors thatpartiallyexplainthesituation.First,itseemsthatriskmanagementisoftenperformedin

an implicit fashion under the general umbrella of project management (Chittister et al.1992). Theymay not consider this type of riskmanagement as something they wouldreportinasurvey.Webelievethatsuchanadhoc,implicitapproachmaybesufficientinsituationswherepeopleinvolvedinriskmanagementhavebeenexposedtothedomainfora longtime, thecomplexityof thedomain is low,and thepastempiricalexperiencecaneffectivelybuildupacorrectunderstandingofrisks.

Therefore,webelieve,anexplicitandsystematicriskmanagementisnotonlybeneficialbutalsocriticalforsoftwaredevelopmentorganizations.Thisviewissupportedbymanyother contributors in this field (Boehm 1989; Charette 1990; Charette 1989) and theBoehm’sspiralmodelevenadvocates that the riskmanagement is theprimarydriver inprojectmanagement(Boehm1991).

Second,projectmanagersandmanagementteamsareconstantlyundertimepressureandthissimplylimitsthetimeavailableforanyactivitiesthatdonothaveanimmediateandconcretebenefittotheproject.Unfortunately,asriskmanagementsolvesfutureproblems,otherurgentissuesoftengetpriority.Clearly,byinvestinginpreventingfutureproblemstherearepotentialgainsthatshouldhelporganizationsavoidthefire-fightingmode.Third,practitioners may not be aware of the available methods and techniques for riskmanagement.Lackingeasytousetools, theysimplymaynotperformriskmanagement.Fortunately, several methods are easily available andmaking them available to projectpersonnel is simply a matter of executives’ decision to deploy such techniques in theorganization.

Fourth,someorganizationshaveaculturethatdiscouragesbringingupnegativeissuesorrisks.Suchclimatemayeffectivelypreventexplicitdiscussionofrisks.Ifrisksareignoredduetothis,organizationwillrefrainfromtakingpreventiveactionandunnecessaryrisksmayoccur,causingproblemsandfinanciallossestotheorganization.Correctandfocusedrisks management activity will not conflict with such a “winning culture”. Instead, itshouldgivepeoplemoreconfidenceinbeingabletoreachtheirgoals.Finally,it isquitedifficult tomeasure the benefits of riskmanagement: successful riskmanagement mayprevent some problems from occurring and very few organizations have good enoughmeasurementsystemsordatapointstoshowtheimpactofriskmanagement.Eventhen,asuccessful risk management practice actually might not even reduce the damage thatoccursinacompanyiftheimprovedpracticesimplyallowstheorganizationtotakebigger

risks that yield higher profits. This last point may be the biggest hurdle preventingeffective riskmanagement to take place in an organization – if themanagement is notconvincedofthebenefitsofriskmanagement, theywillnotsupportandenforceit inanorganization. Many risk management approaches have been proposed in the softwareengineering field since 1980’s when Barry Boehm (Boehm 1989) and Robert Charette(Charette1989)broughtthedisciplineintothemainstreamfocusinthefield.

Thesoftwareindustryisoperatinginanincreasinglyriskybusinessenvironmentandrisktaking is required for success (Charette 1999), yet the industry practice of riskmanagement is largely either absent or based on limited and biased practices. Theunderlying motivation for this work is to improve the industry practice in softwareengineering risk management. We hope to make a contribution that will allow moreeffective control of risks, leading to improved success rate of even more challengingprojects.Wehave articulatedourmotivation andviewof the industryneeds as a set ofsuppositionsthathavebeenusedasabasisofourwork:

S.1Moreeffectiveriskmanagementmethodsandtechniquesneedtobeusedinsoftwareprojectstoimproveprojects’successrate.

S.2Riskmanagementmethodsinsoftwaredevelopmentmustbesystematicandexplicitsothatresultsaretransparentandcommunicabletovariousparticipantsandstakeholdersoftheproject.

S.3Riskmanagementmethodsusedinsoftwareprojectsmusthavelowoverheadandbeabletoproduceconcreteresultsquicklyinordertobeusedinpractice.

S.4Benefitsofriskmanagementmustbedemonstratedandmeasuredmoreeffectivelysothattheindustrydecisionmakersbecomemoreconcretelyawareoftheimportanceofriskmanagement. In this work, we have developed a risk management method that avoidslimitations common to many current approaches while being a practical and feasibleapproachinindustrialprojects.Theriskmanagement improvementframeworkpresentedinthisworkprovidesexamplesandguidelinestoestablishacontinuouslyimprovingriskmanagement system into an organization.We also report on the empirical studies thatapplied this method. These studies acted as initial validation of the method that wedeveloped, as well as provided empirical feedback on the method itself and on riskmanagement in general, allowing us to improve our understanding of riskmanagementandtoimprovethemethoditself.

The termriskmanagementhasbeenused in twomeanings in thesoftwaremanagement

literature.Ononehandithasbeenusedtorefertothedisciplinethatthatstudieshowtoidentify,address,andeliminaterisks(Boehm1989),ontheotherhandithasbeenreferredtoastheactivityorprocessthatattemptstoidentifywhatcouldgowronginaprojectandtakingstepstoavoidsuchproblemsinadvance(Charette1989;Dorofeeetal.1996;Hall1998).Inthiswork,weusethetermriskmanagementtorefertoactivitiesthataretakentoidentify,analyzeandcontrolrisks.Weusethetermriskmanagementprocesstorefertoasystematic and explicit riskmanagement activity. The riskmanagement process can beseen as having the inputs and outputs presented in Figure 2: the input of the processconsistsofprojectcontextinformation,goals,andplansfortheproject.Riskmanagementmethods and tools are used to support risk management, and the process delivers twooutputs:understandingoftherisksandriskcontrollingactions[75].

Figure4:RiskManagementProcess[75]

PURPOSEOFSOFTWAREENGINEERINGRISKMANAGEMENT

Riskmanagement in software projects has different uses. It helps to saveprojects fromfailing due to different factors such as non-completion of projects within the specifiedschedule,andbudgetconstraints,andnotmeetingcustomerexpectations.

Riskmanagementlooksatprojectsfromdifferentperspectivestoensurethatthethreatstothe projects are identified, and analyzed, and appropriate strategies are undertaken tomitigate, and control risks. The mitigation strategies may not necessarily mean thecancellation of tasks that involve risks. Many tasks are undertaken in the softwareindustriesevenafterknowingthatundertakingtheminvolvestakinghighrisks.Thehigh-risk tasks are sometimes important to provide the industries a leading edge over theircompetitors.

Themainpurpose of riskmanagement is to knowall possible risks to a project, assesstheir severity, and consequence, and then determine resolution steps depending on thenatureoftherisks.Theideaistominimizeanyunforeseenandunexpectedissuesarisingduring the course of the project by properly planning for eventualities. Proper planningleads to minimizing uncertainties, which might lead to a “turbulent” completion, or acompletecancellationoftheprojects.

Software engineering risk management takes a preventative approach leading tocompletionofprojectswithinpredictabletime,andmoney.Infact,risk-managedprojectshavetheabilitytoreduceprojectcosts,andtimeofcompletion,andincreasetheoverallqualityoftheprojectdeliverables.Withoutthese,projectscouldrisklossofrevenue,andcustomer trust in an average case, or a complete bankruptcy of the participatingorganizationsintheworst.

Risk management in software has been in existence for many decades. However, asmentioned earlier, it is only in the last decade, and a half or so that it has gainedwidespreadimportanceinthesoftwarecommunity.Thesoftwaredevelopmentprojectsinthe early years of the last century conducted risk management using different ad hocapproaches, without following any systematic methodologies. However, with theincreasingcomplexityofsoftwaredevelopment,industrieshaverealizedtheimportanceofriskmanagement, because it helps in reducing the uncertainties involved in developingsoftware,anddecreasingthechancesofprojectfailures.

Beforeapplyinganyriskmanagementprocess,theprojectteammembersshouldbeclearaboutthefollowingdimensionsofrisksintheirprojects(SmithandPichler,2005):

•Thenatureofuncertaintyinvolved,andthelikelihoodwithwhichtheriskwilloccur.

•The loss thatwillbe incurred if the riskoccurs.Loss in softwareprojects can takemany forms including lossof revenue, lossofmarket share, and lossof customergoodwill.

•Theseverityoftheloss.

•Thedurationoftherisks.

POPULARSOFTWARERISKMANAGEMENTMODELS

Several software riskmanagement approaches have been proposed in the past,most ofwhich assess risks during all the phases of software development, by integrating riskmanagementpracticesalongwiththesoftwaredevelopmentprocess.Asaresult,intheseapproaches,theriskmanagementmodelsfollowadisciplinedprocess.Theseapproachesarelistedbelow.

•Boehm’sRiskManagementModel(Win-Win)[146144,145,147]

•SEI’sSoftwareRiskManagementModel(SREVersion2.0)[148]

•Hall’sRiskManagementModel(P2I2)[149]

•Karolak’sRiskManagementModel(Just-In-TimeSoftware)(Karolak,1998)

•Kontio’sRiskitMethodology(Kontio,1997;Kontio,2001)

These approaches are summarized below. A “horizontal” comparison of all of theseapproachesmaynotbefairbecause,althougheachofthemaddressriskmanagement,theywere developed under different circumstances for solving may be related but different

issues. For example, Hall’s P2I2 was developed from a risk management capabilitymodeling perspective. On the other hand, Boehm’s Win-Win model was developedprimarilyasanovelsoftwaredevelopmentprocessmodel(“spiral”development)takingarisk-basedapproach.Weprovidebelowahigh-leveloverviewoftheseapproaches.

Boehm’sFoundationalContributions:Boehmproposedasoftwaredevelopmentmodelthatwasrisk-driven.Thestrengthofhismodel, referredtoas theOriginalSpiralModel

(Boehm,1988),eliminatesrisksfromtheearlystagesofsoftwaredevelopment,insteadofencounteringprojectbarriersatthelaterstages.

BoehmextendedhisOriginalSpiralModelusingtheTheoryW(Win-Win)Model(BoehmandRoss,1988;BoehmandBose,1994),whichaimsatsatisfyingtheobjectives,and concernsof the stakeholders.TheWin-WinModel also supports risk identification,resolution,andcontinuousmonitoringofrisks.AlthoughthestrategytakenbyWin-Winmaynotalwaysbeattainableinpractice,itisanimportantcontributiontowardsengagingstakeholdersintheriskmanagementprocess.

Boehm(1991)alsoproposedariskmanagementframework,whichhelpstoidentifytheprimarysourcesofrisk,analyze,andresolvethem.ThisriskmanagementframeworkcanbeintegratedintotheOriginalSpiral,ortheWin-WinModel.

SEI’s Software Risk Management Approach: SEI provided a comprehensive riskmanagementframeworkcomprisingof thefollowingthreegroupsofpractices:SoftwareRisk Evaluation, Continuous Risk Management, and Team Risk Management. TheSoftwareRiskEvaluationapproachconcernstheidentification,analysis,communication,and mitigation strategies for software risk management. The approach depends on,amongst other elements, the risk taxonomy, which consists of constructs used fororganizing risk information. The taxonomy helps in providing with an instrument(questionnaire) to elicit different classes of risks. The entire taxonomy of risks can befound in (Higuera and Haimes, 1996), and is omitted from here. The taxonomy hasclassificationofrisksintocategoriessuchasRequirementsrisks,Designrisks,Codingandtestingrisks,Contractrisks,Resourcerisks,andsoon.

Continuousriskmanagementtakesaprinciple-basedapproachforprovidingprocesses,methods,andtoolsforcontinuouslymanagingrisksduringallthephasesofsoftwarelifecycle.

Team riskmanagement, on the other hand, is also a principle-based practice, butconcernsthedevelopmentofmethodologies,processes,andtoolsfordevelopingworkingrelationshipsbetweenthecustomers,andsuppliers.

All thesethreegroupsofpracticesarehelpful toeachother.Forinstance, takingateam-orientedapproachforriskmanagementhelpsincontinuouslymanagingrisks.

Hall’s P2I2 Approach: Hall (1998) approached risk management by identifying fourdifferentfactorsthathavethepotentialtoaltertheexpectedresultsinanyproject.ThesefactorsarePeople,Process,Infrastructure,andImplementation.

ThePeoplefactor isconcernedwithhumanresourceaspectsforriskmanagement.Thisisimportantbecausethesuccessofanyriskmanagementactivitiesisdependentonthe successful communication of different issues arising while conducting riskmanagementactivities.

TheProcess factor defines theprocesses that shouldbe taken tomanage risks forminimizinguncertaintiesinvolvedintheproject.

TheInfrastructurefactordefinestherequirements,resources,andresultsrequiredtoperformriskmanagementactivitiesinanorganization.

TheImplementationfactorconcernstheactualimplementationofriskmanagementactivities such as, establishing the initiatives for riskmanagement, developing the plan,customizing the standard processes to meet the requirements of the project, assessingrisks,andcontrollingrisks.

Karolak’sApproach:Karolak(1998)tookaJust-In-Timeapproachforriskmanagementinsoftwareengineering.TheJust-In-Timeapproachattempts tominimize theamountofrisks involved,whileoptimizing thecontingency strategies forproblematic situations. Ittakesarisk-drivenapproach,andadvocatestheprincipleofmanagingriskduringtheearlyphasesofsoftwaredevelopmentlifecycletoreduceprojectcost,andtime,andimprovingcustomerexpectations.

In his approach, he first identifies a set of high-level risk categories. Then heassociates theseriskcategories toriskfactors, riskmetrics,andquestions tobeaskedtoproject stakeholders. These questions are useful as checklists for identifying differentclassesofrisks.

Kontio’s Riskit Approach: Kontio (2001) proposed the Riskit methodology, whichprovides a complete conceptual framework for risk management using a goal-, andstakeholder-orientedapproach.Itattemptstomanagerisksbycapturingtheintentionsofstakeholdersintheriskmanagementprocess.

The implementation of the Riskit methodology helps project managers with theaccurateandtimelydisseminationofprojectinformation,opportunity,andrisktodifferentstakeholders, thereby enabling to make critical decisions for the overall success of theproject.

Riskitalsohelpsforsystematicallymanagingtheprojectstartingfromidentification,andanalysisofrisktothemonitoring,andcontrolofthem.

AttheheartoftheRiskitapproachisthedesigningoftheRiskitAnalysisGraphforanalyzing risk factors, risk events, risk outcomes, risk counter-actions, risk effects, andutilitylossthatwouldoccurduetoariskevent.

KontioalsoproposedariskmanagementprocessimprovementframeworkusingconceptsfromVictorBasili’sExperienceFactory(Basili,1993).Therefore,theactualunderstandingoftheRiskit

ProcessManagementImprovement(PMI)FrameworkrequiresanunderstandingofExperienceRepository.WithoutgettingintothedetailsoftheExperienceRepository,wementionthattheessentialideaunderlyingKontio’sRiskitPMIFrameworkisutilizingexperience,andinformationfromprevioussoftwaredevelopmentprojectsformanagingrisksinthecurrentproject.

Theoverallgoalistoimproveindustrialpracticeofriskmanagementbydevelopingandproviding improved methods, tools, and insights to support software engineering riskmanagement.Theresearchprobleminthisworkisdefinedintothreemainobjectives,aslistedbelow:

1. Develop a comprehensive, theoretically sound, and practical method for softwareengineeringriskmanagement.

2.Develop a framework and supporting software tools for the continuous improvementofsoftwareengineeringriskmanagementandforimprovingknowledgeaboutrisks.

3. Evaluate the method in practice to provide information on its feasibility,effectiveness,advantagesanddisadvantages,andtoimproveit.

DevelopaRiskManagementMethod

Thestartingpointfordevelopingtheriskmanagementmethodandtoolwastosynthesizefindingsandrequirementsfromtheliteratureaswellasfromourpersonalexperienceinriskmanagement.Wesurveyedthe literatureandsynthesizedourpreviousexperience inriskmanagementtoformulatespecificrequirementsforthemethodwedeveloped(Caplan1994;Chittisteretal.1992;Diekman1992;Edgar1989;Garrabrantsetal.1990;Garrick&Gekler1991;Hall 1994;Hefner 1994;Kahneman et al. 1982;Kontio 1994a;Kontio1995a; Lyytinen et al. 1993;Meyers & Trbovich 1993; Rook & Cowderoy 1993; SEI

1993; SEI 1994; SEI 1995; Simister 1994; Williamson 1994). We used the criteriaproposed by Garrabants et al (Garrabrants et al. 1990) as a basis for the developmentrequirementswesetforthemethoddevelopmentandreviewedthemfromtheperspectiveofourownexperienceinriskmanagement(Kontio1994a).

Experienceinriskmanagementleadsustoaddtworequirements to the listproposedbyGarrabrants. First, risk management in an organization is a communication challenge:different perceptions and opinions need to be shared and consolidated during theidentificationandanalysisandtheresultsofriskanalysisneedtobecommunicatedwithseveral stakeholders. Second, cost effectiveness is a prerequisite for a riskmanagementmethod to be used in practice: project managers have severe time constraints and riskmanagementactionsneedtoprovideaddedvaluewithlimitedeffort.

Therefore, we added need for communication and cost-effectiveness to the methodrequirements, modified the criteria slightly for our purposes, and synthesized the riskmanagementmethodrequirementsaspresentedinTable8.

Table8:Requirementsforthemethoddevelopment[75]

TheRiskitmethodwasdeveloped to satisfy these requirements.However, theempiricalstudies (Englund 1997; Freimut et al. 2001; Getto & Landes 1999a) (Getto & Landes1999b;Kontioetal.1996;Kontio&Basili1997;Kontioetal.1998)conductedduringthisdevelopment provided additional feedback and requirements to the method and themethodhasbeenrevisedtoincludesuchfeedback.

DevelopanImprovementFramework

AswiththedevelopmentoftheRiskitmethoditself,wefollowedasimilarapproachforthe development of the improvement framework for the method. We surveyed theliterature (Basili 1989;Basili 1993;Bhandari et al. 1993;Bollinger&McGowan1991;Card 1991; Curtis & Paulk 1993; Dion 1992; Humphrey & Sweet 1987; Thomas &McGarry1994), reflectedonourownpersonal experience inprocess improvement, andsynthesized the requirements for the riskmanagement improvement framework.Basili’sQuality Improvement Paradigm (QIP) forms a foundation of the Riskit improvementparadigm(Basilietal.1992b;Basili&Green1994).

In this work, we consider the QIP as a paradigm that has threemain components: theExperience Factory Organization, the Experience Base, and the QIP cycle. We alsoconsidered alternative improvement paradigms for the Riskit process improvementprocess.Twomajorparadigmswereconsidered:maturitymodels,inparticulartheCMM(Paulk et al. 1993a) and SPICE (Anon.1998c); and Hall’s risk management maturitymodel (Hall 1994; Hall 1995). CMM and SPICE were rejected because they lackedsufficientdetailsonriskmanagementandforrepresentingastaticviewonkeyaspectsofprocessimprovement(Kontio1995b).

Hall’s maturity model was rejected as it also represented a static view on processimprovement and for the lack of evidence for its validity. However, note that thesedifferentparadigmsarenotnecessarilyconflictingwiththeQIP.Whiletheydifferinmanykey aspects, they can be used to complement and extend risk management processimprovement,astheydoaddressseveralaspectsofriskmanagement.Basedonoursurveyand analysis of our own experience, we formulated the requirements for the riskmanagementframeworkaspresentedinTable2.

Table9:Requirementsfortheimprovementframework[75]

The improvement framework for risk management was developed by instantiating andCustomizing the Experience Factory concept for risk management. This essentiallyrequiredthedefinitionthefollowingaspectsoftheframework:

Definitionoftheriskmanagementimprovementprocess,includingidentificationofinformationflows.

Definitionofrolesandresponsibilitiesintheprocess.

Definitionofinformationtypesanditemstobecreated,used,andcapturedduringtheprocess.

Definitionandimplementationofasoftwaretooltosupporttheexecutionoftheriskmanagementprocess,aswellasthecapturingoftheinformationcreatedduringtheprocess.

Definitionofasetofempiricaldesignsandsupportingdocumentation.

EmpiricalEvaluation

The third objective of this work was to evaluate the method and the improvementframework in practice to provide information on their feasibility, effectiveness,advantages, and disadvantages; and to improve them. This was done in a series ofempiricalstudiesthatcoveredvariousaspectsofthework.Table10liststhesestudiesandexplainstheircontributiontothework.

Table10:Listofempiricalstudiesandtheirobjectives[75]

Software development requires members of the software development team to make anumber of decisions including choices of technology, software development methods,usageofprototypingand inclusionof requirements. Inorder tomake thebestdecisionsindividualsneedtoknowhowtomakethebestdecisionsandtheymustbemotivatedtomakethosedecisionsinthebestinterestoftheorganization.

Muchcurrent research implicitly assumes thatmembersof theproject teamaremakingdecisions in the best interest of the organization and improvements to the softwaredevelopment process will come through development and implementation of bettermethodologies.However,puttingbettermethodologiesinthehandsofindividualsthataremotivatedbytheirownself-interestcanhaveadetrimentaleffect.Ifindividualsdonotusetheirabilitiesinthebestinterestoftheorganization,softwarefailurecanbeexpectedevenwithwell-developedmethodologies.Thefourauthoritativeapproaches,Boehm’s(1991),

Davis’s (1982),McFarlan’s (1981), andAlter’s andGinsberg’s (1978), have dominateddiscussionsofriskmanagement(Lyytinenetal.,1998).

Traditional approaches to manage risk consist of identifying risk and finding ways ofcontrolling the risk.Applyingmodern softwarepractices [123], using good requirementanalysis,versiondevelopmentandevolutionarydevelopmentcanhelptoreducecommonknownrisks.However,noneof thesemethodsaddresses the inherentnatureofsoftwaredevelopment risk and the human nature of risk propensity. The following paragraphsdiscusssomeofthemethodologiesandtheirshortcomings.

Classicaldecisiontheoriesthatdefineriskasthevariancebetweenpossibleoutcomesandmodelthedecisionprocessbasedonexpectedvalueofdecisionsdonotaccuratelycapturetherealbehaviourofmanagementdecisionmakers(MarchandShapira,1987).Itismoreaccuratetodescribethemasbeingattentivetothemagnitudeoflossandseekingtoavoidlargelosses(MarchandShapira,1987).Withthisinmind,largelossesasperceivedbyamanageroranotherpersononasoftwaredevelopmentteammustbeconsideredinlightofthe individuals’attention to individualvs.organizationalgoalsand thedecisionmaker’spropensitytotakerisk.

Lyytinen et al., (1998) have argued that a socio-technical approach considering actors,structure,task,technology,andtheirinteractionsintegratespreviousresearchonsoftwaredevelopmentriskmanagementandprovidesaricherdescriptionoftherealworldsystem.Althougheachisimportantandallmustbeinbalanceforbestorganizationalfunction,theactors arequite central in the sense that theyaremakingdecisionsbothat the softwaredevelopment project level and at the organizational level, shaping their work tasks,structures,and technology.Further, inaprofessionalenvironment,anumberof typesofactors,manyofwhomarenotmanagers,aremaking“managerialdecisions.”

Always operating without complete information, managers and others involved in asoftware development project must make satisfying decisions. A problem in anyorganization is thatmanagersmaynot alwaysmakedecisions in thebest interestof theorganization, but rather maymake them in their own interest. Project leaders, systemsanalysts, programmers, end-user, and others involved with software development mayhavedifferentintereststhantheorganizationinwhichtheyworkanddifferentpropensitiesforrisk.

Figure5showsourmodelofhowindividualriskpropensityandmotivationeffectsprojectsuccessor failure.Propensity to takerisk ismitigatedbycontrolmethodologies thatareintended to prevent individuals from taking unwarranted risk. The type of contract or

rewardsystemmitigatesthemotivation.However,controlmethodologiesmayalsoaffectthemotivationofindividualsandtherewardswillaffectpropensitytotakerisks.

Figure5:ModelofindividualbehavioronFailure/Success[1]

Riskanalysisusuallyassumesthatthereisaconstantriskforfailureofsoftwareprojectsand that probability can be assigned to these failures. Methods are then suggested toreduce the risk of these potential failures. It is commonly believed that reducinguncertainty will reduce the risk of failure (Zmud, 1980). One of the factors whichcontributetoanincreaseinfailureofsoftwareprojectsandwhicharenotwidelydiscussedintheliteratureisthepropensityofpeopletotakerisks.Individualsconfrontedwiththesameriskoftenactverydifferently.Oneexplanationisthatdifferentpeoplehavedifferentutility functions. People may be considered risk neutral, risk averse and risk takingdependingontheirutilityfunction.

Considerthreesituations:apersonhasthreechoices,[1]receiving$50,[2]receiving$200withprobability0.5andlosing$100withprobability0.5,[3]receiving$2,000,000withprobability0.0001andlosing$50withprobability0.9999.Theriskaversepersonwouldchoosethe$50withcertainty,whilearisktakerwouldpreferthebet[3].Theriskneutralpersonwouldconsiderallbetsessentiallythesame,astheexpectationisaboutthesame,namely $50. Confronted with a risk, individuals will balance the uncertain rewards ofactionsagainstthepotentiallosses.

Although, everyone has a propensity to take risks this propensity varies from oneindividual to another and is influenced by the potential rewards of risk taking, theperceptionsof riskand theexperienceof failureorsuccess. Ingeneral, themorerisksarationalindividualtakes,thegreater,onaverage,willbeboththerewardsandthelosseshe/she incurs. Adams (1999) presents this balancing act in a so-called risk thermostat(Figure6).Rewardsare influencing thepropensityofaperson to takeriskasdofailureandlossesinfluencetheperceiveddanger.

Figure6:RiskThermostat[150]

Thusasoftwareprojectmanagerwhohasexperiencedfailuresmaytake lessrisk thanaproject manager who has little experience. Individual risk-taking decisions represent abalancingactinwhichperceptionsofdangerareweighedagainstpropensitytotakerisksandthepotentialrewardsandfailureresultinginlosses.

Every day, every individual must make decisions from driving to work, eating certainfoodstoinvestinginretirementtonameafew.Everysuchdecisioninvolvesbalancingtherewardsagainstuncertainlosses.Individualsinvolvedinsoftwareprojectsfrommanagerstoprogrammersperformthesamebalancingact.Forinstance,amanagerwillbalancetherewardofhavingasysteminashorttimeagainsttheriskoffailureofarushedproject,orthepromisedrewardsofa“comprehensivesolution”againsttheriskoffailurebecauseofprojectcomplexity.

Allriskmodelsassumethatthereissomeprobabilityoffailure.However,theestimationofprobabilitiesisoftendifficultandsubjective(Barkietal.,1993).Probabilitiesarewelldefined in the mathematical literature. The following approaches are accepted, theclassicalmethodthatderivesprobabilitiesfromamodel,thefrequencybasedprobabilitiesandsubjectiveprobabilities.Thesubjectiveprobabilitieshoweverhave thedisadvantageofbeingnotverifiable.

Different individuals may derive different probabilities. Boehm (1991) for instancerecommendsusingthreeintervalsfortheprobabilities.Adams(1999),however,pointsoutthe scientific elusiveness of risk assessment. “The clouds do not respond to what theweather forecaster say about them. People do respond to information about risks, andthereby change them “[150]. For instance, wearing a seat belt while driving a carunquestionablereducestheriskofacarcrashbeingfatal.However,“…aspeopleperceivethemselvesassaferorbetterequippedagainstadanger,theyaremorelikelytotakemore

risks.”[150].

Hence, the probabilities for other risks are changing. For instance, the probabilities forinjuryandpropertydamagecrashesmayactuallyincreasebecausedriverstakemorerisks.Similarly, individuals involved in softwareprojectsmaychange theirpropensity to takerisks based on changes in perceived risk of failure. As more and more softwaredevelopmenttechniquesareusedandtechnologyadvancesindividualsmaytakemoreriskandthuschangetheprobabilitiesoffailure.Overconfidenceinanewtechnologyandthesubsequentbeliefofinvincibilitymayinvitecatastrophicfailures.

Totheextentthatsoftwaredevelopmentrisksareanalyzedandresearched,itwillalterthebehaviour of people and thus change the risk because people will act upon this newinformation.Forinstance, justasmorehighwaysignsofdangerswillmakethemotoristdrive more carefully, established methodologies and risk management in softwaredevelopment will make failure less likely. However, people will also expect that allsignificantdangerwillbe“signposted”,thusincreasingthepotentialriskoffailure.Justasreduced perceived danger increases the risk taking, increased perceived danger mayreducepropensity to take risk.For example,manydangerous roadshavegood accidentrecords because people know that they are dangerous. In the same way known risksawarenessinsoftwaredevelopmentmayreducetheirprobabilityofoccurring.

Much research has focused on using methodologies to avoid failures by directly orindirectly controlling the risk behaviour of individuals. We may consider them as the“traffic laws” of software development.However, as crash statistics show over 80%ofdriverfatalitiesinvolveexcessiveriskstakingsuchasalcohol,speedandnotwearingseatbelt.Allofthesefactorsareaddressedbylaws.Hence,individualbehaviournotexternalfactors aremost often to blame.Makingmore laws (methodologies)may not decreasefailure. Any improvement has to address the motivation of the individuals. In thefollowing sections we discuss some of the common methodologies used in softwaredevelopmentintendedtoreduceriskofprojectfailure[1].

Table11:BoehmTenriskFactors[5]

2.3.NeedforRiskManagementThe work focuses on risk management in software development projects or programs.More specifically, we are studying and developing methods, tools and techniques forpeopleinvolvedinriskmanagementinsoftwareprojects.Thedevelopmentofthemethodand its improvement framework included the definition of process, information flows,rolesandresponsibilities,informationtypes,andthetemplatesusedintheprocess.

The results of this work are intended to be applicable to any kind of softwaredevelopment,as thewide rangeof applicationdomain coveredby the empirical studiessuggests.However,we believe that large organizations and complex projects are morelikely tobenefit from theresults of this research.Small organizationsor trivial projectswillbeabletoconducttheirriskmanagementmoreintuitively.Whilethedomainofthisresearch is software development, we believe that the methods developed are quiteapplicable toanygoal-orientedactivity,suchasproductdevelopment ingeneral,projectbasedindustries,manufacturingandbuildingindustry.

However,tovalidatesuchclaimsisbeyondthescopeifthiswork.Wealsobelievethatthebasicconceptsofourresultscanalsobeusedinbusinessriskmanagementandstrategicplanningbutagainourintentisnottostudysuchapplicationopportunitiesinthisresearch.We have surveyed several other fields in our literature survey part of our research.Wehave included contributions and insights from economics, psychology, organizationaldevelopment, government, and engineering to construct our method and tailor it to

softwareengineeringdomain.However, ithasnotbeenour intent toverifywhetherandhowourfindingscouldbeappliedintheseotherfields.Whendealingwithsoftwarerisks,theriskscausedbytheoperationofsoftwareareoftenalsoconsidered.

As our primary focus has been to support software development organizations indevelopingtheirproducts,wehaveexcludedtheevaluationandmanagementofrisksthatmight occur during the operation of software. Again, it is plausible that many of theunderlyingprinciplesandmethodsdevelopedinthisresearcharealsoapplicabletorisksin operating software, but in order to control the focus of this research we have notaddressedsuchissues.

A critical issue in software engineering risk management work is the identification ofgeneric,or typical, risks in specific subdomains,understanding their characteristics, andprovidingsupport forcontrolling theseriskseffectively.Asseveralotherresearchersareaddressingtheseissues(Carretal.1993;Jones1994;Laitinenetal.1993;Monarchetal.1996;Ropponen&Lyytinen2000),wehavenotattemptedtoincludesuchtopicsintothescope of this work. However, we believe that both the Riskit method and the riskmanagement improvement framework presented in this work provide a basis forresearchingcommonordomainspecificrisksmoreeffectively[75].

IMPORTANCEOFRISKMANAGEMENT

Risk management encompasses three processes: risk assessment, risk mitigation, andevaluation

and assessment. Section 3 of this guide describes the risk assessment process, whichincludes identification andevaluationof risks and risk impacts, and recommendationofrisk-reducingmeasures.Section4describes riskmitigation,which refers toprioritizing,implementing, and maintaining the appropriate risk-reducing measures recommendedfromtheriskassessmentprocess.Section5discussesthecontinualevaluationprocessandkeysforimplementingasuccessfulriskmanagementprogram.

The DAA or system authorizing official is responsible for determining whether theremainingriskisatanacceptablelevelorwhetheradditionalsecuritycontrolsshouldbeimplemented to further reduce or eliminate the residual risk before authorizing (or

accrediting) theITsystemforoperation.Riskmanagement is theprocess thatallowsITmanagers to balance the operational and economic costs of protective measures andachievegainsinmissioncapabilitybyprotectingtheITsystemsanddatathatsupporttheirorganizations’ missions. This process is not unique to the IT environment; indeed itpervadesdecision-makinginallareasofourdailylives.

Takethecaseofhomesecurity,forexample.Manypeopledecidetohavehomesecuritysystems installed and pay a monthly fee to a service provider to have these systemsmonitored for thebetter protectionof their property. Presumably, the homeowners haveweighed the cost of system installation and monitoring against the value of theirhouseholdgoodsandtheirfamily’ssafety,afundamental“mission”need.

Theheadofanorganizationalunitmustensure that theorganizationhas thecapabilitiesneeded to accomplish its mission. These mission owners must determine the securitycapabilitiesthattheirITsystemsmusthavetoprovidethedesiredlevelofmissionsupportin the faceof realworld threats.Most organizations have tight budgets for IT security;therefore, IT security spending must be reviewed as thoroughly as other managementdecisions. A well-structured riskmanagement methodology, when used effectively, canhelpmanagementidentifyappropriatecontrolsforprovidingthemission-essentialsecuritycapabilities[151].

Riskmanagement in software projects has different uses. It helps to saveprojects fromfailing due to different factors such as non-completion of projects within the specifiedschedule,andbudgetconstraints,andnotmeetingcustomerexpectations.

Riskmanagementlooksatprojectsfromdifferentperspectivestoensurethatthethreatstothe projects are identified, and analyzed, and appropriate strategies are undertaken tomitigate, and control risks. The mitigation strategies may not necessarily mean thecancellation of tasks that involve risks. Many tasks are undertaken in the softwareindustriesevenafterknowingthatundertakingtheminvolvestakinghighrisks.Thehigh-risk tasks are sometimes important to provide the industries a leading edge over theircompetitors.

Themainpurposeof riskmanagement is to knowall possible risks to a project, assesstheir severity, and consequence, and then determine resolution steps depending on thenatureoftherisks.Theideaistominimizeanyunforeseenandunexpectedissuesarisingduring the course of the project by properly planning for eventualities. Proper planning

leads to minimizing uncertainties, which might lead to a “turbulent” completion, or acompletecancellationoftheprojects.

Software engineering risk management takes a preventative approach leading tocompletionofprojectswithinpredictabletime,andmoney.Infact,risk-managedprojectshavetheabilitytoreduceprojectcosts,andtimeofcompletion,andincreasetheoverallqualityoftheprojectdeliverables.Withoutthese,projectscouldrisklossofrevenue,andcustomer trust in an average case, or a complete bankruptcy of the participatingorganizationsintheworst[152].

CHAPTER-3

ImplementationofRiskManagementinSoftwareProjectDevelopment

3.1.IdentifyingRisksDespitetheinherentrisksassociatedwithsoftwaredevelopmentprojects,therearestrongindicators that these risks can be managed successfully. Research of failed softwareprojectsshowedthat“theirproblemscouldhavebeenavoidedorstronglyreducediftherehadbeenanexplicitearlyconcernwithidentifyingandresolvingtheirhigh-riskelements”(Boehm, 1991). Effective risk management is the most important management tool aproject manager can employ to increase the likelihood of project success. Since riskmanagement is notwidely used and understood, this could be a significant competitiveadvantagetothosethatimplementtheriskmanagementprocessesintheirprojects.

Alargenumberofprocesseshavebeengeneratedinrecentyearstoaddresstheneedformoreeffectiveriskmanagement.TheriskmanagementprocessprovidedinthePMBOK(PMI,2001)isagoodoverviewofthetypicalprocesses,yetitisoftentoogenerictomeetthe specific needs of software projects. The Software Engineering Institute (SEI) hasdevelopedtheTeamSoftwareProcess (TSP )fortheteamasawhole,andthePersonalSoftwareProcess (PSP )fortheindividualduringsoftwareprojectdevelopment(SEI,2001).KeshlafandHashim (2000)havedevelopedmodels for tools toaid the softwareriskmanagementprocess.

AsshowninFig.7, itusesaneight-stepprocessduring the initialphasesof theproject.

Whenanynewrisksareidentifiedthroughouttheproject,afive-stepinnerprocessisusedto improve earlier estimates and judgments continuously. ‘Team riskmanagement’ is aprocessthataddressestherisksassociatedwithmultipleentities(Higueraetal.,1994).

Figure7:‘SoftRisk’model’sdiagram[153]

The ‘team reviews’ section is the principal process thatmakes the teamprocess uniquefromothergeneralprocesses.Theobjectiveofteamriskmanagementistosharetheriskresponsibilityandburdentoeffectivelylowertheriskofallentitiesinvolved.YacoubandAmmar (2002) described a heuristic risk assessment methodology that uses dynamicmetricsobtainedfromUnifiedModelingLanguage(UML)specificationstodeterminethemost risky componentsof the software architecture. It ismathematical analysismodelsderivedfromtheUMLdiagram,andenablesmoreattentiontobeplacedintheareasofthesystemwithhighestrisk.Eventhesimplestmathematicalmodelscontainatleastaratingschemeallowsmanagerstoquantifyandprioritizetherisksduringtheprocess.

A concept used by many of these rating schemes is risk exposure (Risk exposure =Probability(Loss)×Size(Loss))BoehmandDeMarco(1997)showedthattheprobabilitycomponent of risk exposure for employee turnover (oneof the highest risk elements ofmostsoftwareprojects)canbereducedby:

Empoweringperformers

Teambuilding

Establishingsignificantincentivebonusesforsuccessfulprojectcompletion

Recognizingoutstandingefforts

Structuringcareerpathsaroundanorganizationsproductlines.

Furthermore,thesizecomponentofriskexposurecanbereducedby:

Implementing software inspections to reduce defects and spread knowledge ofproductcomponentsamongvariouspeople

Usingegolessprogramming

Cleanroomtechniques

Modularsoftwarearchitectures

Encapsulation

Goodconfigurationmanagement.

Although the foregoing strategies help to overcome the risk exposure tomany risks indeveloping software, this is simply called good programming. Good programmingmethods reduce risk as well as have a positive effect on other project facets such asdevelopmenttime,teammorale,andproductquality.

Methodologyforidentifyingriskfactors

Therearesomemethodologiesforidentifyingvariousriskfactorsasbelow:

(i).Questionnaire(Q):Questionnairesareusedwhenanopinionis tobegatheredfromthepublicoragroupofpeoplefromdifferentlocalities.Questionnairesaregenerallynotdescriptiveandjustprovidepossibleoptionstochoosefrom.Thequestionnairetechniquesuffersfromthebuilt-indisadvantageofbeingleastexplanatoryandmosttimeexpensive,also the response gained from the survey is normally delayed. A survey can only berecommended if it is performed in adequate time limits required by the softwaredevelopmentdeadlines.[154]

(ii).DirectCommunication(DC):DChasdifferentmeaningsindifferentcircumstances,e.g.DCmeanscommunicationbetweentheriskmanageranddevelopmentteamwhileatsome other point DC would reflect the meanings of communication between therisk/project manager and the customer, and sometimes it may be from risk/project

manager to the management of the organization itself. The DC methodology is a bitslowerissuggestingtheresponse,astheprojectmanagerhastodiscussthedetailsabouttheprojectcircumstancesbeforeadecisioncanbemade,thereforetheresponsebecomesslowerandsomeresourcesaretobeinvestedtogettheresponse.Italsotobenotedthatthe respondents of aDC take this time out of their normal schedule inwhich they aresupposedtoperformsomeotherdutiesaswell.[154]

(iii).Experience&Knowledge(EK):Manyriskscanonlybeidentifiedbyrecallingthesuccessesandfailuresinthepreviousprojects.Theintuitioncanworkasamagicandcanonlynothelpinidentificationofriskfactorsbutalsointheeffectivemanagementoftheidentified risks by incurring least resources. The methodology EK has the build-inadvantage of saving time and resources and as only experienced people practice thismethodology, the probability of its appropriate use is very high, and therefore properresults can be derived by using this methodology [154]. A Suitability Index (SI) isdeterminedinthisregard.TheSIvalueof1showsthatsomeriskfactore.g.xcanonlybegenerated by some specific methodology e.g. EK, which also mean that other twotechniqueshavenocontributionintheidentificationofthatriskfactoratall.

The SI value 0.05means that the identification of a risk factor e.g. y is just minutelydependentononemethodology i.eDC,and the rest0.95 is coveredbyeitherEKorQ.likewise theSI value of 0.0 for anymethodologymeans that thismethodology has gotabsolutelynoroletoplayintheidentificationoftheriskfactorunderconsideration.Intheproceedingsectionweuseascaleofvaluesrangingfrom0to1withamultipleof0.05.Thehigherthevalueagainstaspecificmethodologythegreatertheroleitwillpossessinidentificationofaspecificriskfactor.Itisalsoworthmentioningthatthevaluesprovidedagainsteachmethodologyhavebeenderivedfromthesurveyconductedbytheauthorandalsobytheauthor‘scontinuesexperienceinthedomainofsoftwareriskidentificationandmanagement, the author has a vast experience and contribution in this domain ofknowledge[155,156,157,158,159,160,and161].

Figure8:SWIforEK,DCandQmethodology[154]

RISKIDENTIFICATIONTECHNIQUES

Several surveys were conducted to identify methodology for risk factors. Riskidentification is a group of activities involved during software development life cycle[162]. Has considered that the management of risk registers is suitable for theidentification of software risk, while [163] believes in categorizing the risks for thepurpose of identification. Joe Hennessy at ISD-NASA (2004), in his report on ISDsoftwareriskidentificationhasdiscussedtheprocessofriskidentificationandhasurgedthatbeforethestartofriskidentificationprocesstheriskmanagementteammustbearmedwith the list of risk already identified in the domain including technical, budget andmanagement risks etc. Joe focuses on the discussion of each identified risk with thedevelopment team and decides an applicability of that risk in the project underconsideration.

Furtherthedevelopmentteammaycheckthateithersomegenericriskfactorthatapplytothe organization apply to the specific project or not? Thus contributing to develop acompletelistofriskfactorsthatisrelevanttotheproject.Joehaspreciselyemphasizedtheneedforcommunicationbetweenthemanager,customer,anddevelopmentteam.[154]

In another report on ―taxonomy-based risk identificationǁ by Software EngineeringInstitute: themethoddescribed in the report consistsofdeveloping the taxonomy-basedquestionnairesforidentificationofsoftwarerisk.Taxonomyisaschemethatpartitionsthebody of knowledge and defines the relationship among the pieces [164]. This reportemphasistheneedofquestionnairesforidentificationofriskfactors.[154]

In another report bySoftwareEngineering Institute (2008), the authorRayC.Williamshas argued that the biggest need in managing the risks is risk identification. Ray hasreferenced a situation in which 40 field tests were conducted with a broad range ofsoftwaredeveloperstoidentifythatwhohavegoodcommunicationskillsandtechniquestohelpintheprocessofriskidentificationwiththeirownexperienceandbyinterviewingothers.

Rayalsoarguesinthefavourofusingthe―inter-organization-communicationǁtoreportany risk that isobservedat any level.He suggests that thehighermanagementmustbeopenwiththemiddlemanagementandworkersbysharingtherisksandinvitingthemtosharetheirs.[154]

In yet another paper on checklist of risk identification by Mark Li (2007), differentmilestonesof risk identificationwith the identificationmethodologyhasbeendescribed.Boehm(1991)identified10riskfactorsbysurveyoftheexperiencedriskmanagers[165].Barkietal.(1993)identified23riskfactorsbyjustdoingthesystematicliteraturereview[166].HeemstraandKusters(1996)identified36riskitemsbydoingtheliteraturesurveycombined with experiences [167]. Moynihan (1997) identified 21 risk factors byInterviewing with 14 application developers [162]. Ropponen and Lyytinen (2000)identifiedsix risk itemsbydoingasurveyof83projectmanagerscoveringnearly1100projects[163].HanandHuang(2007)identifiedsixdimensionsof27risksbyananalysisof115softwareprojects[168,154]

Effective risk management: To achieve the promise of fully effective software riskmanagement,thesoftwareindustrystillmustaddressseveralcontinuingchallenges.

a) Achieve commitment of all key stakeholders (developers, customers, users,maintainers,andothers)toariskmanagementapproach.

b) Establish an evolving knowledge base of risk management experience andexpertise,organizedforeasyandcollaborativeusebyallstakeholders.

c) Define and propagate mature guidelines on when and how to avoid, prevent,transfer,oracceptandmanagerisk.

d) Develop metrics and tools for reasoning about risk management’s returnon-investment issues, includingguidelines fordecidinghowmuchofa risk reductionactivity is enough. Tools that might be used in this way include risk-focusedprototyping, specifying, testing, formal verification and validation, configurationmanagement,andqualityassurance.[169]

Some important Risk Factors are Inadequate Requirement Description, Project SizeEstimation,ProjectFundingLoss,ManagementChangesCircumstances,StaffTurnover,Staff Inexperience, Loss Of Actual Documents And Data, Lack Of Intuition, LowEstimation Of Time, Developer’s Lack Of Commitment, Customer’s Dis-Satisfaction,Change In Hard-Ware Defaults, Requirement Postponement, Development teamcontinuous work, Immature Coding Practices, Presence Of Bugs And Errors, Over-Acceptability Of Product And Insufficient Data Handling, Delayed ImplementationSuffering,MarketDenial,Hackers,VirusesAndTrojanHorseEtc,OverEstimationAboutWorkers Skills, Lack Of Technical Feedback, Save Prestige Not Money, BuildingLoss/Fire,EconomicDistortion[154]

Risk-basedtestinginvolves:

1.Makeaprioritizedlistofrisks.

2.Performtestingthatexploreseachrisk.

3.Asrisksevaporateandnewonesemerge,adjustyourtestefforttostayfocusedonthecurrentcrop[170].

ASoftwareDevelopment ImpactStatement (SoDIS)process ispresentedwhichextendstheconceptofsoftwareriskinthreeways.First,itmovesbeyondthelimitedapproachofschedule, budget, and function, second it adds qualitative elements, and lastly itrecognizesprojectstakeholdersbeyondthoseconsideredintypicalriskanalysis.

Figure9:RiskManagementProcess[171]

3.2.ProblemsofRiskAnalysisanditsneed

Theproblemsofriskanalysiscanbeaddressedinseveralwaysincluding:

1.Expandingthelistofgenericrisks,

2.Maintainingfocusonthebroaderprojectgoals,and

3.Extendingthelistofconsideredprojectstakeholders.

Boehm(1991)identified10softwareriskitemstobeaddressedbysoftwaredevelopmentprojects:

Personnelshortfalls

Unrealisticschedulesandbudgets

Developingthewrongfunctionsandproperties

Developingthewronguserinterface

Goldplating(addingmorefunctionality/featuresthanisnecessary)

Continuingstreamofrequirementschanges

Shortfallsinexternallyfurnishedcomponents

Shortfallsinexternallyperformedtasks

Real-timeperformanceshortfalls

Strainingcomputer-sciencecapabilities.

Jones (1998) further presented three key software risk factors and concerns of bothexecutivesandsoftwaremanagers.

Risksassociatedwithinaccurateestimatingandscheduleplanning

Risksassociatedwithincorrectandoptimisticstatusreporting

Risksassociatedwithexternalpressures,whichdamagesoftwareprojects.

LimitationsofCurrentApproaches

Thereisnoshortageofproposedapproachesforriskmanagement.Itisperhapssurprisingthatmanyexistingapproacheshavevariouslimitationsthatareoftennotacknowledgedoraddressedbyauthorsorbypractitioners.Thereasonforthismaybethatriskmanagementin software projects always contains a dilemma: one expects reliable results with littleeffortandinvestment.Afterall,aproject’sgoalistodeliverproducts,nottospendallofitstimeonponderinghypotheticalproblems.

Nevertheless,failuretoaccountforthelimitationsintheriskmanagementapproachusedmayresult in seriousbias in riskmanagement results.Sometimes these limitationsmayhavelittlepracticalrelevanceandtheydonotnecessarilyindicatethatariskmanagementmethod does not work in practice. However, most of them have a high potential forcreatingbiasinriskanalysissowerecommendthatanyriskmanagementprogramshouldtake a conservative position and “prove” that the limitations are not serious in theirsituation.

Manyriskmanagementapproachesaddressalimitednumberofgoals,suchasschedule,cost and product quality (Gemmer & Koch 1994; McCaugherty 1996; Sisti & Joseph1994). There are many cases where projects actually have important other goals thateventuallyaffectprojectssuccess,suchas impactonreputation,ability to reuseprojectsresults,compliancewithconstraintssettotheproject,needtomaintaincompatibilitywithothersystems,andprocessconformance requirements. In fact,project’sgoalscan rarelybetruthfullyexpressedintwoorthreegoals.Ifariskmanagementapproachlimitsitsriskidentificationandlossevaluationapproachestotoofewgoals,somerisksmaybeignoredorrankedlowerthantheyshould.

Fewriskmanagementapproachesexplicitlyrecognizethedifferentexpectationsdifferentproject participants, stakeholders, have on the project and its goals. Sometimes thecustomer and other stakeholders are involved in the risk evaluation process (Sisti &Joseph1994),buttheinvolvementofsuchpartiesdoesnotnecessarilyguaranteethattheirinterestsaresupported in riskanalysisphase.Even ifotherstakeholdersare involved inthe analysis, a joint, consensus-based ranking of goals may not be the most effectivemechanism to dealwith these stakeholder perspectives: itmay increase communication

overheadandsometimespoliticspreventopendiscussionofcriticalissueswhendifferentstakeholdersarepresent.

Many organizations have attempted to streamline their risk identification processes bydevelopingriskchecklistsortaxonomies(Bezirkan&Mulazzani1994;Boehm1989;Carretal.1993; Jones1994;Rook&Cowderoy1993;Speaker1993).Thesecanbehelpfultoolsinmakingsurethatallpreviouslyidentifiedcategoriesofriskarecovered.However,such taxonomiesmay also increase the tendency of participants to focus on the issuescovered by the checklist and limit their ability to use their independent judgment toidentifyrisksoutsidethechecklist.

The results of such taxonomy or checklist based risk assessments are sensitive to theappropriatenessofthetaxonomyusedfortheprojectandsituation.Ifthetaxonomydoesnot cover the “right” risks in a situation, the results are likely to be wrong. Anotherpotential problem with taxonomies is that they inherently contain trade-offs betweencoverage,detail,anduserfatigue.Ataxonomythathasbroadcoverageandisdetailedmayresultinuserfatigue:theytendtobecomelessalerttowardstheendofthetaxonomylist,possiblyfailingtorecognizesomerisks.

WEIGHTAGEOFTHEMETHODOLOGY

Ithasbeenobservedthatallthreemethodologiesusedforidentificationofriskfactorsinasoftwaredevelopmentenvironmenthavegotcertainprosandconswhicharebuilt-inwiththemethodology itself, e.g. themethodology EK‘ has the build-in advantage of savingtime and resources and as only experienced people practice this methodology, theprobabilityofitsappropriateuseisveryhigh,andthereforeproperresultscanbederivedby using this methodology. The DC‘ methodology is a bit slower is suggesting theresponse,astheprojectmanagerhastodiscussthedetailsabouttheprojectcircumstancesbeforeadecisioncanbemade,thereforetheresponsebecomesslowerandsomeresourcesaretobeinvestedtogettheresponse.ItalsotobenotedthattherespondentsofaDC‘takethistimeoutoftheirnormalscheduleinwhichtheyaresupposedtoperformsomeotherduties as well. The Q‘ technique suffers from the built-in disadvantage of being leastexplanatory and most time expensive, also the response gained from the survey isnormallydelayed.Asurveycanonlyberecommendedifitisperformedinadequatetimelimits required by the software development deadlines. In light of above discussion, aweightage index is suggested keeping in view the build-in pros and cons of eachmethodology[3].

PROBABILISTICIDENTIFICATIONOFEACHRISKFACTOR

Theapproachfocusesontheidentificationofeachriskfactoranditisarguedthatwhichtechnique,outofavailablethree,canbemostbeneficialinidentificationoftheriskfactor.Theapproximateweightage isbeinggiven toeachmethodologybasedon its suitability,whichissupportedbythesurveyconductedinthisregardandtheauthor‘sintuition.

A.InadequateRequirementDescription

It is often known to the project manager that the customers can hardly describe theadequate amount of information about their requirements. Although the manager canidentifywith its experience that the requirements are incomplete and tend to change infuture,yettheoverallmeasuretowhichtherequirementsaremissingandcanchangecanonlybeknownthroughbyusingtheDC.

B.ProjectSizeEstimation

Calculatingtheactualsizeoftheprojectunderconsiderationhasbeenaseriousquestioninthesoftwarecostestimationdomain.Ithasbeenobservedthatthequestionnairecanbeofverylittlehelpinthisregardnotonlybecauseofthegeneralirresponsivenessbutalsobecauseofthenaturaldisabilityoflessdescriptive.DCwiththecustomerandwithinthedevelopmentteamshelpsalotinidentifyingtheactualprojectsize.Theexperience‘playsavital role in identificationof theactualproject size, andwithoutexperienceother twomethodologiestendtofailbadly.

C.ProjectFundingLoss

Duetotheinadequatehandlingoftheprojectinthebeginning,orforanyotherreasontheprojectmaynotmeetthemilestonesandconsequentlydeliverydeadlinescannotbemet.An effective project manager can, by using his experience promptly, very effectivelypredict about the development delays and can propose extrameasures in achieving the

milestones. Questionnaire oriented information gathering regarding this risk factor hasbeenextremelyun-helpful.SuchriskcanonlybeidentifiedeitherbyexperienceormainlybecauseoftheDC.

D.StaffInexperience

Asexpertiseandexperienceof the individualsworking inanorganizationareknown tothemanagement,therefore,themosteffectivewayoffindingtheexpertiseofindividualsis through theDC.Questionnaireshavebeen found tobeof leastusefulnessbecauseoftheirdescriptivenatureand immaturity.Thedevelopersalsomaynot like toprovide thewritten proof about their deficiencies, etc. Experience also plays a vital role in theidentificationofanysuchriskfactor.

E.StaffTurnover

Staff turnover isoneof themostdynamically facedchallengesnotonly in the softwaredevelopmentorganizationsbutalso ingeneralaswell.Thechangeof jobcanhardlybeevaluatedbythequestionnaire.DCcanbeofhelponlywhentheemployeehasshownitsintentionsinadvancetoleavethejob.Theexperiencedmanagers,however,canestimateandexpect somestaff turnoverduring the lifetimeof theproject. Inestimating the staffturnover,nothinghasbeenfoundmoreappropriatethantheexperiencewhichallowsthemanagerstoplanaheadandtrainandattachsomeextraworkforcewiththeproject.

F.ManagementChangesCircumstances

Change of circumstances to meet the deadlines is considered normal when therequirements are deficient in exploration at the beginningof the project.The change inrequirementsdirectlyeffectsthetimeandbudgetallocatedfortheproject,inordertocopewiththis themanagerneedstochangecircumstancestoaccommodatethechanges.Thisriskfactorisquiteevidentanditsexistencecanbeestablishedeitherbythequestionnairesorbycommunicatingtothemanagerandcustomersdirectly.Experienceandintuitionstillplayavitalroleintheidentificationofanysuchriskfactor.

G.LossOfActualDocumentsAndData

Thelossofdocumentsanddataisnotacommonriskfactorinthesoftwaredevelopmentlifecycle.Lossofdataanddocumentcanbeforanyreason,includingthetheft,fire,lossetc.An experiencedmanager can have amplewisdom about the risk andmaintains thedataonmultiplesitesandserversandduplicatecopiesofdocumentsarealsomaintained.DChasalsoamajorroletoplayintheidentificationofthisriskfactor.Thequestionnairemethodologyhasbeenobservedtobeofleastsignificanceamongthethree.

H.LowEstimationOfTime

Due to the inbuilt and perhaps genuine problem of the requirement statement by thecustomer,thedevelopmentteamremainsincontinuousloopforafairlylongerperiodtotime to finalize the requirements and based on that the time and budget for theaccomplishment of the project are also calculated.Questionnaire‘s approachmay be ofslighthelpbuttakesahugeamountoftimeandhencestandslessadequateintheraceofbeingthefittest.DCallowsthemanagertocommunicatewiththedevelopmentteamandthecustomertomanagethisrisk.Ithasbeenobservedthatanexperiencedmanagerwillalreadyknowthatthisriskcancomeandhecanidentifysuchriskswiththeexperience.

I.LackOfIntuition

Useofintuitionplaysamajorroleinsmellingtheoutofboxproblemsandcansuggestthepossiblesolutions.Thelackofintuitionmaymeanthatadevelopmentteamworksmoreandyieldsless.Inordertomaketheteamproductive,itisnecessarythattheyareadvisedtolearnfromexperience,usethere-usablecode,becoherentwiththecircumstancesandalsokeeptheireffortssynchronized.Thelackofintuitionmustbeidentifiedbythehighermanagement and when identified should be immediately in place. Although theidentification of this risk factor can be done well by the experience and directcommunicationmethodologies,yet thequestionnairemethodologyhasbeenofadequateimportanceintheidentificationofthisriskfactor.

J.Developer’sLackOfCommitment

The project starts with a positive node assuming that the work force deployed on theprojectisloyal,motivated,andcommittedbutsometimesthesituationmaybeotherwise.It isofutmostimportancethat therolesofeachindividualarediscussedbeforetheyareassigned.Thiscanhelp inkeeping thedeveloperscommitted to theirwork.As this riskfactorisevidentonlyafterthestartoftheproject,agoodmanagercanidentifythiskindofriskbeforethestartoftheproject.Suchriskfactorscanbeidentifiedeitherbyusingtheexperience or by direct communication but not by questionnaire‘smethodology by anymeansasanun-committeddeveloperwillnotlikeadmittingaboutitslackofcommitment.

K.Customer’sDis-Satisfaction

With the emergence of agile computing and prototypemodels of software developmentthecustomersroleasanactiveentityhaveincreasedgradually,overthetime.Customersnow have the liberty to show the consent about the development under consideration.Keeping in view, that a dis-satisfied customer may cause the funding uncertainty the

manager can use the questionnaire or direct communication to get the feedback of thecustomerandcanelaborateonthatbyusinghisexperience.

L.ChangeInHard-WareDefaults

Thisriskfactorismorecommonfortheproductsthatarenotdevelopedforsomespecificcustomerbut for thepublic.Thedevelopment teammust ensure that theydonotwaste(take)ahugeamountoftimetodeveloptheproduct,sothatthehardwaredefaultsdonotchangewhen the product becomes available to use. This has to be donewith immensespeed,asthehardwaredefaultsarechangingdynamically,presently.Themanagerofthedevelopmentteammaynothavethelibertytousethedirectcommunicationwiththefirmsdeveloping the hardware. Thus, generally, the manager has to rely either on his ownexperienceoronthequestionnairethatmaycontaintheprobabilisticquestionstoforecastabout the future development in the hardware defaults. Even if such changes in thehardware are known, the development teammay not easily adopt them with the samepace.

M.Developmentteamcontinuouswork

Thisriskfactororiginateseitherbecauseofthechangeintherequirementsorbecauseofthe continuous business of the organization. It has been observed that the softwaredevelopershavetoworkmorethantheirfixedtimingsinordertomeetthedeadlines.Itistherefore important that sufficient manpower is placed to e ensure that each employeeworksfornotmorethan4ohoursaweek,innormalcircumstances.Asthefuturebusinessof the organization can hardly be forecasted, therefore the direct communication andquestionnairecanhelpinidentifyingthisriskfactor.

N.RequirementPostponement

Requirementgatheringisdifficultbecauseofthefactthatthecustomermaynotexplicitlymentionwhatheneeds.Insuchcase,wheretherequirementsarehardtofinditisproperlyinadequatetopostponethegatheredrequirements.Theideaofpostponementcomesonlywhenthedevelopmentteamtriestomakethecustomerhappybyshowinghimsomethinginstead of the complete working product. Being up-to-date with the project scope andmilestonestheprojectmanagercandirectlycommunicatewiththedevelopmentteamandcustomertoseeifsomerequirementscanbescrubbed.Anexperiencedmanagercanalsoprepareaquestionnairefor thecustomertoseewhichrequirementscanbepostponed, if

any.

O.ImmatureCodingPractices

Theimplementationbeingthecoreoftheprojectrequiresmoreattentionascomparedtoanyotherphaseinsoftwaredevelopment.Inordertoensurethatthedevelopmentteamisdoing the coding accurately, purposefully and error free, it is necessary that suitablecodingpracticesareintroducedintheorganization.Theemployeesmaybetrainedandtestfor having the adequate standards of software development. If the coding standards areinadequate, themanager has to know thismuch earlier otherwise the failure or at leastdelayof theproject isguaranteed.Directcommunication,Questionnaire,andexperienceareallimportanttoidentifythisriskfactorrespectively.

P.PresenceOfBugsAndErrors

Itisadequatelyimportantthatthedeveloperunittesteachmoduleandpieceofcodethattheyhavedeveloped,inordertoreducethechancesoferrorsatlaterstage.Morelatelyanerror is identified, the cost to rectify will be higher. Direct communication andquestionnairescanhelpintheidentificationoftheseriskfactorswhiletheexperiencecanhelpinrectifyingtheidentifiederrors.

Q.Over-AcceptabilityOfProductAndInsufficientDataHandling

Innovationsaregenerallyappreciated inanydomain.Sometimes, theproductdevelopedbyafirmisoverwhelminglywelcomedinthemarketandhencethestressonapplicationincreasesboth:intermsofaccessrateandintermsofdatastorage.Ifanysuchapplicationhasbeenpublicizedwithalimitedstorageandinadequateresponsetimethelikelihoodfortheapplicationcrashwillincrease.Themanager,whiledevelopingtheproductmustalsoidealizeabouttheoverwhelmingsuccessoftheproject.Themanagermusttrytoprovideasmuchfunctionalfacilitationsaspossiblebynotdisturbingtheefficiencyandreliabilityofthesystem.Assuchsituationsarenotcommon,experienceofmanagermaynotbeofadequate help. Therefore this risk factor can better be identified by using the directcommunicationandquestionnaires.

R.Hackers,VirusesAndTrojanHorseEtc

Thetestingteammustensurethat thesystemimplementediserrorfreeandmustensurethatamechanismis inplace torestrictanyfriendlyorunfriendlyprogramtoaccess thesystem without permission. The manager may also contribute to provide the updatedversionsofanti-viruses toensure themaximumsafetyagainstanysuchevent.Althoughthis risk can more easily be identified with experience, yet the orientation of this risk

factorisalsopossiblethroughdirectcommunicationwithdevelopmentteamandalsobyprovidingthequestionnairestoreplyaccordingly.

S.DelayedImplementationSuffering

Software requirements are not easy to determine and determined requirementsmust beimplementedwithoutanydelay.Adelayedrequirementimplementationmakesthejobofthedevelopmentteamdifficultandconsumesextraresources.Everyexperiencedmangerisawareoftheproblemsthatcanbefacedbecauseofthedelayedimplantation.

T.MarketDenial

Market denial has been a serious issue in the product development. The company‘smanagementmusthavedoneadequatestudyabouttheacceptabilityoftheproductinthemarketbeforetheactualworkontheproductstarts.Thecompleteorpartialmarketdenialafter the competition of a product can suffer the business andmarket reputation of anorganization.Theorganizationcanbeindirectcommunicationwiththemarketorcanputasurveytoidentifytheacceptabilityofaspecificproduct.Theexperiencedmanagercanalsouseitsintuitioninthisregard.

U.OverEstimationAboutWorkersSkills

The cost to be over-optimistic is very high is software cost/time estimation. Whilecalculating thecost and time requiredcompleting theproject theanalystsandmanagerssometime over estimate the skill of their workers and under estimate the scope of theproject.This leads toahuge failureas themovement fordeveloping the software startsand immediately themanagement knows about the risk ofmiss-calculation and realizesabouttheoverestimationabouttheworkersskill.Worker‘sskillsaregenerallyknownandcan be further tested either through questionnaire or by communicating directly. TheweightageofeachmethodologyinSIwillbeas.

V.LackOfTechnicalFeedback

The requirement gathering process requires a thorough consideration and effectivecommunication at the level of team leader/analyst and technical people at the customerside.Theheadoforganizationmustnot signacontractwithoutconsultinghis technicalteam tominimize the chance of reduction in profit. The development teammust try tocoverallrequirementsinthefirstiterationandnottoleaveanyrequirementsunaddressed.It has been observed that more requirements identified in the beginning leads to lesschangesinthefuture.Byexpectingonlyafewchanges, inthefutureitcanbeexpectedthattheprojectcanleadtoasuccess.Theexperiencedmangercanidentifythisriskeither

bydirectcommunicationwithcustomerorbyputtingaquestionnaire.

W.SavePrestigeNotMoney

Ithasbeenobservedthatthecustomeroptstogetitssoftwaredevelopedfromthereputedsoftware development firms only.The reputation of firms is decided not only based onrevenuesbutalsoonthebasisofthegoodwillandcordialrelationshipsthattheyhavewithothergroups.Afailedprojectnotonlyharmstherevenuesofthefirmbutalsodisturbsthereputationaswell.Therefore,thefirmstrytheirhardnottoletaprojectfailandevenatthecostoffinanciallosses,theywouldliketosavetheirnametomaintainthereputationandgoodwillofthemarket.Itisimperativetostatethatariskshouldalwaysbeidentifiedbefore it actually starts harming the system. Once the risk has shown his presence, itdoesn‘t remain in isolationand invitesother risk factors tomakeameshand insure theprojecttodelayifnotfailatall.Soinordertocontinuegainingbusinessinthefuture,thefirmmayliketodeveloptheprojectsuccessfullyevenbygoinginfinancialdeficit.Theexperiencedmangercanidentifysuchsituationbycommunicatingwithmanagementandcustomers:directlyorbysendingquestionnaires.

X.EconomicDistortion

The management of software development firm must try to commit advance paymentfrom the customer if the economic situation of the country/market is not stable. In theeconomiccrisis,thefirmmusttrymaximizingitsprofitandshouldtrytoprovidebenefitstotheemployeestoenablethemtofacethepooreconomicsituation.Althougheconomicdistortionsmay be difficult to identify well in time, yet the experiencedmanagers canhave adequate vision to predict such events. The manager can communicate with topmanagementandcustomerstoidentifytheeconomicdistortion.

Y.BuildingLoss/Fire

Thefirmmustensurethattheworkingenvironmentacrosstheorganizationconduciveandsafe for the employees.Proper smokedetectors and fire alarmsmustbe installed in thebuilding todetect the fire and theemergencyexit shouldbeprovided .Theorganizationmustalsoensurethatthebuildingcodeshavebeenfollowedandthestructureisaccordingtotheprescribedstandards.Themanagementmustkeenlyobservethebuildingstructureand the life of building must also be known by communicating with architects andmanagement.

3.3.RiskManagementProcessTheprocessisasfollows:

1.IdentifyingRiskfactors

2.Assessriskprobabilitiesandeffectsontheproject

3.Developstrategiestomitigateidentifiedrisks

4.Monitorriskfactors

5.Invokeacontingencyplan

6.Managethecrisis

7.Recoverfromacrisis[43]

ITRISKANALYSIS

Analysis of IT risk is undoubtedly key element of the process of Information Systemssecuritymanagementandthereforemanagementofrisk.Publicationsconnectedwiththeseproblems–bothdomesticandinternational–seemtotreatitinarbitraryway.Itmanifestsinmultitudeofdefinitionsofriskanalysis,andalsointhefact thatriskanalysisisoftenidentifiedwithitsmanagement[12].Riskanalysisismainandthemostimportantprocessofriskmanagementidentifiesandevaluatesriskwhichhastobecontrolled,minimizedoraccepted.RiskanalysisiscomprehensiveidentificationofthreatsandsusceptibilityifITsystem’sassetsanddeterminationof theneedof itscontroloracceptanceofdeterminedmeasuresatpreviouslystated level.Theaimof riskanalysis isprovisionof informationwhichisindispensablefordecisiononapplicationofspecifiedmethods,securityresourcesintheenterprise.

Riskanalysis inclines tocarryoutworks inareas [4,p.283-284]:−Resourceevaluation

(information,software,hardwareandphysicalresources)–valueofresourceitisnotonlyvalue of its purchase but also short term effects and long term consequences from itsdestruction, −Assessment of consequences – definition of the degree of destruction orlosses,whichcansupposedlyoccur,−Identificationofthreats–analysisofthreatsshoulddetermineprobabilityofitsoccurrenceandpossibilityofresourcedestruction,−Analysisofprotectionsintheaspectofeffectivenessofexistingmeansofprotections,−Analysisofsusceptibility of particular IS resources, −Assessment of probability, it is frequency ofthreat occurrence – this mark should embrace presence, duration time and strength ofthreat,andprotectionsInformationofsuchtypewillalwayshaveapproximatecharacter,however accurate, based on i.e. experiences of another enterprises, execution of riskanalysismaybeveryhelpful in realizationofnextprocessesofsecuritymanagement inorganization. However, very important problem of estimation and evaluation ofInformationTechnologyriskisleft.

RESEARCHMETHOD

Thissectiondescribestheresearchmethodtakenduringourstudy.

A.ResearchSteps

Duringthefirststep,westudiedasetofriskmanagementprocessmodels.Toachievebothbreadth and depth of the riskmanagement domain,we chose publications of renownedindustrial and academic institutions, including: (1)international and organizationalstandards, e.g. [203][212][216],(2) academic and industrial models, such as [194][197][198][212],and (3) various investigations made by individual researchers or researchergroups,e.g.[199][204][214].Themodelsstudiedvarysomewhatwithrespect tosomeofthefundamentalsofriskmanagementasidentifiedin[207][208].

Inordernottomissanything,wehavethereforesynthesizedasubsetofthesemodelsintoone common model. Our goal was to create as comprehensive a model as possiblecovering all the issues as suggested by the current risk management models. Thesynthesizedmodelisbasedon[195][199][201][205].ItisdescribedinSectionIII.

As a third step, we determined the comparison criteria to be used in our study. Thesecriteria cover the fundamentalaspects of riskmanagement as identified in [208].Using

them,we thencreatedaquestionnairewhosequestionswerebasedon (1) thesecriteria,(2) the synthesized risk management process model [211], and (3) a template of riskmanagementinformation[209].

In the fourth step, we used students to make the interviews. The students attended anadvanced international software engineering course. In total, 37 interviews wereconductedwith representatives from 37 different software organizations. Finally, in thefifthstep,weanalyzedtheanswersandestablishedastatuswithinthecompanies.

B.Questionnaire

Thequestionnaireusedinthisstudyconsistedoffourparts.AscanbeseenitTable1,inthefirstpart,“SectionA–Introduction”,weenquiredabout thebackground informationconcerningtheintervieweesandtheirorganizations.Inthesecondpart,“SectionB–RiskManagement”, we investigated the state of risk management practice within theorganizationsstudied.

Inthethirdpart,“SectionC–DevelopmentandRiskManagementProcessIntegration”,we exploredwhether and how the organizationsmanaged to integrate riskmanagementwith their development processes. Finally, in the fourth part, “Agile versus TraditionalProcesses”,westudiedintegrationofriskmanagementwithagilemethods.Allthesepartsconstituteabasisforourevaluationcriteria.

The questionnaire used in this studywas open-ended and semi-structured. The purposewas to give freedom to respondents to answer in their own terms. Such type ofinterviewinghasapositiveeffectinasensethatwhileinterviewing,onemayelicitmoreknowledgeaboutthestudieddomain.Itsdrawbackhoweveristhefactthattheinterviewermustpossessagoodunderstandingofthedomainstudied,inordertoadequatelyreacttoirrelevantanswers.Duetothefactthatweusedstudentsinourinvestigation,werun theriskthatsomeanswersmightbemisunderstood.

Toavoidmisunderstanding, threepreventiveactionswere taken.First,wepresentedourriskmanagementmodelindetailtothestudents.

Second, detailed directives regarding the expected answers, and possible follow-upquestionswereinsertedintothequestionnaire.Thegoaloftheinterview,thequestionsandthe questionnaire design were also described and discussed in class together with thestudents.Third,theintervieweeswereaskedtoprovidetheirnamesandcontactdetailstoallowtheauthorstocontactthemwithfollow-upquestions.

C.SamplingandValidity

Thedatasamplingmethodwasconveniencesampling[213].Thismeansthatwedidnotcontrolthechoiceoftheorganizationsinvolvedinourstudy.Itwasstudentswhodid it.Duetothefactthatitwasdifficult tomakeorganizationsshowwillingforaninterview,the students were allowed to choose just any organization (large/medium/small and/orprivate/government)inanycountry.

Theonlyrequirementwasthattheorganizationsstudiedshouldhaveariskmanagementprocessinplace.Manyofourstudents,comingfromaninternationalmasterprograminSweden,choseorganizations in theirowncountries.Hence, thecountries represented inthis report are China, Colombia, Denmark, Finland, Germany, Iran,Mexico, Morocco,Pakistan, Thailand, USA, Spain, and Sweden. Due to the sensitivity of the materialpresentedherein,we do not name them. Some of them however aremajorwell-knownmultinationalorganizations.

SYNTHESIZEDRISKMANAGEMENTPROCESSMODEL

Thissectiondescribesoursynthesizedriskmanagementprocessmodel.Itconsistsofsixphases:RiskIdentification(RI),RiskAnalysis(RA),RiskManagementPlanning(RMP),Risk Monitoring and Control (RMC), Risk Sign-Off (RSO) and Risk Post-MortemAnalysis(RPMA).

A.RiskIdentification

DuringtheRiskIdentificationphase,onemakesaninventoryofpotentialrisksthatmayhave impact on the achievement of the predetermined objectives [36]. The phase startswithpreparatoryactivitiesfortheactualriskelicitation[30].Itcontinueswiththeactualrisk elicitation using various techniques such as brainstorming, interviews, scenarioanalysis,prototyping,andthelike[203][212].

Whendoingit,oneidentifiesrisks,theirconsequences,effects,sources,rootcauses,andcategories [203]. Finally, one creates a risk list and circulates it around all the relevantstakeholdersforpossiblecomplementaryadditions,improvements,andconfirmation.

B.RiskAnalysis

During the Risk Analysis phase, one analyzes and prioritizes risks [195]. First, oneanalyzeseachriskindependentlybystudyingtheidentifiedriskandassessingits impact,probability, risk exposure and severity [215]. The analysis can be conducted using

different techniques, e.g.matrices, decision trees and scenario analysis [212].One thengroups and analyzes the related risks to facilitate their collective mitigation [212].Afterwards, one consolidates the risk prioritization and creates a top-priority risk list[195].Basedon the analysis results; one suggests a preliminary planformanaging eachriskorriskgroup.Finally,theprioritizedrisklistiscirculatedamongthestakeholdersforconfirmation.

C.RiskManagementPlanning

In the Risk Management Planning phase, one creates concrete plans determiningstrategies, options, and actions relevant for managing the identified risks [203]. AsdepictedinFig.5,onestartsthephasewithstudyingtherisklist,theanalysisresults,andthepreliminaryplan[212].Foreach riskor riskgroup,one firstdetermines appropriatestrategies[212],andthencreatesanddocumentsthefollowingthreeplans:

•ControlandMonitoringPlandefiningrelevantmeasuresormetrics formonitoringandcontrollingtherisks[212],

•RiskActionPlandetermining the actions to be used for treating a certain risk or riskgroup[36],and

•ContingencyPlanspecifyingtheactionstobetakenincaseswhensevererisksturnintoaseriousproblem[212].One thencombines all the threeplans intoone comprehensiveRiskManagement Plan [203]. To ensure that the identified risks get full attention, oneprepares contractual agreements, where each risk owner’s responsibilities are specifiedand agreed upon [212]. Finally, one circulates updates and confirms the plan and itsrelateddocumentation.

D.RiskMonitoringandControl

In the Monitor and Control phase, one continuously monitors and controls the risksaccording to the riskmanagement plan.One also continuously identifies new risks. Tomake certain that risks are effectively monitored and controlled, one first ensures thatthere are riskmonitoring procedures established. For each risk or risk group, one thencontinuouslymonitorsandrecordsthestatus[212].Incaseswhenthestatuschanges,onetakesmeasures as specified in theplan.Finally, oneupdates and records the risk status[203].

E.RiskSign-Off

Aformalsign-offphase isan importantpartof riskmanagementassurance[215].Here,onefirst reviews the risks and theway they have beenmitigated. For each risk that isjudgedtobemitigated,oneupdatestheriskmanagementprogressstatus,removesitfromtherisklist,andensuresthattherisklistgetsupdated[215].Finally,onesignsitoff.

F.RiskPost-MortemAnalysis

IntheRiskPost-MortemAnalysisphase,onecollectsandevaluatestheriskmanagementprocessanditsresults.Here,oneevaluatestheinformationabouttheidentifiedrisks,theircauses, treatment, the process used and the successes or failures of the actions taken.[203]. Using it, one then creates or updates the organizational risk taxonomy [212], ifneeded.Finally,oneidentifiessuccessesandfailuresintheprocessandgenerateslessonslearned[203].This, in turnprovides an important historical feedback for improving thefutureriskidentificationandmanagementprocess[215].

EVALUATIONCRITERIA

Thissectionpresentsourevaluationcriteria.SectionIV.Alistsanddescribes thecriteriathatwereusedwhencomparingoursynthesizedriskmanagementprocessmodelwiththeindustrialmodels.

A. Criteria for Comparing Risk Management Process Models with the IndustrialPractice When studying the industrial status of riskmanagement,we used ninecriteria that covered some of the fundamental aspects of risk management [208]. Thecriteriaandtheirrelatedquestionsarebrieflydescribedbelow.

•Riskidentificationpractice:Riskisaneventoraconditionthatmayaffecttheoutcomeofaproject [203]. Its identificationandclassification is a prerequisite for effective riskmanagement [203].Questions10and11 investigatewhether and how the organizationsstudiedidentifyandcategorizerisks.

•Riskmanagementprocess:Theriskmanagementprocessconsistsofasetofphasesandactivities thatarenecessaryforconductingriskmanagementonsoftwareprojects [212].ThephasesgenerallyconsistofRiskIdentification,RiskAnalysis,RiskActionPlanning,RiskMonitoringandControl,RiskSign-off andPost-MortemAnalysis [203][205][212][216].

•Rolesandresponsibilities:Stakeholderrolesareindividualrolesorrolegroupswhohaveastakeinormaybeimpactedbyagivenactivity[203].Thecoverageofstakeholderroles

within riskmanagement is important. It is only then onemay be sure that all the risksources and targets have been identified and scrutinized from all possible perspectives.Designation of roles is a prerequisite for defining risk management process andresponsibilitieswithintheprocess[205]

• Use of models, standards and guidelines: External risk management models andstandardsexisttoprovidecriticalguidanceindefiningariskmanagementprocess.

• Risk recording and documentation practice: A clear, complete and correct riskdescription is an important prerequisite for its effective management [197]. To aid inmaximizingthequalityoftheriskinformation,oneshoulddocumenttheriskandprovideguidelinesforwhatinformationshouldbemanagedduring theriskmanagementprocess[202].

Fig.10:OnewayofcategorizingrisksinOrganization15

Usingthiscriterioninkindofriskmanagementinformationisrecorded.Useofsupportingtools: To enable effective risk information management, analysis and tracking,organizationsneedtoolsandrepositoriesfordocumentingtherisksandriskmanagementprocess[203].

• Scope of risk management: Risk management is recognized as best-practice in thesoftware industry[196]. Incurrentmodels, it isdirected to softwareprojects ingeneral.However,wewishtoinvestigateifthereareanydifferencesintheirapplicationdependingon,forinstance,theprojectcharacteristics.Inordertoidentifythescopeofapplyingriskmanagement,we examine if riskmanagement is applied in all types of projects in theorganizationsstudied

•Riskmanagementprocessproblems:Problems related to the riskmanagementprocessprovide a good platform for evaluating the process, identifying its deficiencies, and formakingprocessimprovements.

•Importanceofriskmanagement:Manyvoiceshavebeenheardregardingtheimportanceof riskmanagement [204]. These voices havemainly been raisedwithin the academia.Littleishoweverknownabouttheattitudetowardsriskmanagementwithintheindustry

B.Criteria forEvaluating the IndustrialPractice of IntegratingRiskManagementwithSoftwareDevelopment

To explore the industrial practice of integrating risk management with softwaredevelopment,weusedthefollowingfiveevaluationcriteria:

•Organizational levels:Most software organizations conduct their business on variousorganizational levels [217]. As illustrated in Fig. 10, they usually distinguish betweenBusiness and Engineering levels [210]. The Business level involves planning of morestrategic nature to establish the product vision, while the Engineering level involvesrealizing thatvisionbyplanninganddeveloping theproduct [206].Riskmanagement isrelevantforbothBusinessandEngineeringlevels.

• Integration aspects: When integrating processes, one needs to identify appropriatecriteria for doing it.Due to the fact that there are very few process integrationmodelsregarding this domain, we inquired about the criteria to be used when integrating riskmanagementwithsoftwaredevelopment.•Integrationproblems:Problems,successesandfailuresprovideagoodplatformforevaluatingtheintegrationattemptsbyindicatingtheirdeficienciesandstrongsides.

•Importanceofprocessintegration:Thesoftwareindustryshouldhaveanopinionabouttheimportanceofintegratingriskmanagementwithdevelopmentprocesses.Thisopinionshouldbe listenedandpaidheed to. Itmayprovide indications of the procedures to beenforcedoravoidedduringintegration.

•Applicability of riskmanagement in agile context:Due to the fact that agilemethodsclaim tobe riskdriven [200],wewished tohear the industrial point of viewabout thisissue

3.4OtheroptionsavailableforRiskManagement

RISKMITIGATIONSTRATEGIESANDPLANNING

RiskMitigation reduces the probability or consequences of a threat. This may includephysicalmeasures(protectivefences)orfinancialmeasures(stockpilingcash,insurance).ItisalsocalledRiskreduction.

Riskmitigation objective is to generate some risk response strategies for high risk thatrequires analysis to be done. For this method, a team is created that is assigned someresponsibilitieshavingateamleaderwhocanbeagencyplanner,engineer,orconstructionmanager,dependingon thepoint inprojectdevelopment,or it couldbeaprivate sectorcontractororpartner,dependingonthecontractingmethodandriskallocation.

Afteranalyzingtherisksateamcaneasilymitigatetherisks.PennockandHaimesoftheCenterforRiskManagementofEngineeringSystemsstatethatthreekeyquestionscanbeposedforriskmitigation:

1.Whatcanbedoneandwhatoptionsareavailable?

2.Whatarethetradeoffsintermsofallcosts,benefits,andrisksamongtheavailableoptions?

3.Whataretheimpactsofcurrentdecisionsonfutureoptions?

An understanding of these three questions is critical to risk mitigation and riskmanagement planning. Question 1 addresses the available risk response options. Anunderstandingofquestions2and3isnecessaryforriskplanningbecausetheydeterminetheimpactofboththeimmediatemitigationdecisionsandtheflexibilityofriskmitigationandplanningonfutureevents.[45]

As statedbyBoehm riskmitigation strategies are avoidance, transfer andacceptanceaspotential risk-mitigation strategies. For the telecomproject, avoidance techniquesmightbetobuymorememoryorafasterprocessorortodeclinetheproject.Transfertechniquesmight include implementing the lowest layers of the communications protocol inhardware,placingthetoplevelsoftheprotocolonanetworkserver,orsubcontractingthework to specialists in communication software. Acceptance techniques require that all

affectedparties (customers,users,managers,developers),publiclyacknowledge the riskfactors and accept them. They also involve preparing action, contigency, and crisis-managementplansfortheidentifiedrisks.[43]

RiskPlanning:Riskplanning involves the thoughtfuldevelopment, implementation,andmonitoringofappropriateriskresponsestrategies.TheDOE’sOfficeofEngineeringandConstructionManagementdefines riskplanningas thedetailed formulationofaplanofactionforthemanagementofrisk.Itistheprocesstodothefollowing:

Develop and document an organized, comprehensive, and interactive riskmanagementstrategy.

Determinethemethodstobeusedtoexecuteariskmanagementstrategy.

Planforadequateresources.

Risk planning is iterative and includes describing and scheduling the activities andprocesses to assess (identify and analyze), mitigate, monitor, and document the riskassociatedwithaproject.Forlargeprojectsorprojectswithahighdegreeofuncertainty,theresultshouldbea formal riskmanagementplan.Planningbeginsbydevelopinganddocumenting a risk management strategy. Early efforts establish the purpose andobjective,assignresponsibilitiesforspecificareas,identifyadditionaltechnicalexpertiseneeded, describe the assessment process and areas to consider, delineate procedures forconsiderationofmitigationandallocationoptions,dictatethereportinganddocumentationneeds,andestablishreportrequirementsandmonitoringmetrics.[45]

Boehm’sRisk-ManagementProcess

Riskmanagementwas introducedasanexplicitprocess in softwaredevelopment in the1980s. The father of software riskmanagement is considered to beBarryBoehm,whodefinedtherisk-drivenspiralmodel[Boeh88]-asoftware-developmentlifecyclemodel–and then described the first risk-management process [Boeh89].Most of the processesdefinedsincethenstemfromhisbasicprocess.Hisrisk-managementprocessconsistsoftwosubprocesses,“riskassessment”and“riskcontrol”(seeFigure11).

Fig.11:BoehmRiskManagement[5]

Therisk-identificationprocessentailslistingallconceivableriskstotheproject.Creativemethods, e.g. brainstorming, and analytical methods, e.g. a risk checklist, can be usedhere.The risk analysis evaluates the risks.This involves determining the probability ofoccurrenceandthepossiblenegativeeffectsforeachrisk.Therisk-prioritizationstageisusedtospecifythesequenceinwhichtherisksaretobedealtwith.Tothisend,thelossescausedwhenrisk eventsoccur are evaluated.Theprocess of risk-management planninginvolvesspecifyingmeasuresintendedtoreducetheprobabilityofriskeventsoccurringorto diminish the negative impacts following the occurrence of the risk event. Riskresolution is the step of the process where the defined measures are carried out. Riskmonitoringkeepstrackoftheefficiencyofthemeasuresimplemented.Inordertodothis

effectively,risk-monitoringmetricsshouldbespecifiedintherisk-managementplanningstageandtherelateddatashouldbecapturedduringtheriskresolutionprocess[5].

Wallmüller’sRisk-ManagementProcess

[Wall99]describesaprocesswherebytherisk-managementactivitiesareconductedbytheproject team at the same as the cost-, time-, quality- and requirement-managementactivities.UnlikeBoehm’s process, this is a sequence-oriented process (see Figure 12).The risk-planning part starts in the project-preparation and planning phase before theactualprojectkick-off.Theprocessrunsfullcircleatleastonceinaprojectphase.Thisisalso referred to as continuous risk management. Many activities are the same as inBoehm’sprocess.

Asignificantnewcomponent is theassignmentofdifferent risk-management roles.Theproject manager determines the general risk-management strategy, including theappointmentoftheriskmanagerandassignmentofrisk-managementresponsibilities.Theprojectmanagerworkswiththeriskmanagerandtheprojectteam(clients,suppliersandsubcontractors)inorder to identifyrisksanddefineprobabilitiesand impacts.Heorsheplansandapprovestheimplementationoffinancial,time-relatedandtechnicalpreventiveandprecautionarymeasures,monitors and establishes reporting procedures.The projectteamidentifiesriskswithinitsareaofresponsibility,appraisesprobabilitiesandimpacts,prioritizes risks, identifies preventive and precautionary measures, reports on the Risk-PlanningRiskControlIdentifyrisks

Fig.12:Wallmüller’sRiskManagement[5]

Dr.E.Wallmüller8of16 statusof risks, evaluates the efficiencyof thepreventive andprecautionarymeasures and implements, if necessary, the precautionary measures. Theriskmanager supports the project team in the risk-planning and risk-control processes,implements the risk-management plan, organizes and administrates risk-status reports,evaluates new risks, checks the effectiveness of current risk plans and of theimplementationofprecautionarymeasures.

Kontio’sRisk-ManagementProcess(Riskit)

Riskit is a goal-oriented and stakeholder-oriented style of risk management [Kont97].Riskit distinguishes between two phases: the initialization phase and the risk-analysiscycle.The latter hasmany parallelswithBoehm’s basic process andWallmüller’s risk-management process. This phase will thus not be described in detail here. In theinitializationphasethefoundationsuponwhichtherisk-managementprocessisperformedarelaid.

Theaimofthefirstprocessstep,“Risk-managementmandatedefinition”,istoestablisharisk-managementprocedurefor theproject inconsultationwithallparties involved(e.g.projectmanager,riskmanagerandprojectteam)(Figure5).Therisk-managementprocessmust be adjusted to the complexity and riskiness of the project. In the case of smallprojects,wherenomajorrisksaretobeexpected,itusuallysufficestodiscussrisksattheprojectmanagementmeetingsfromtimetotime.Incomplex,high-riskprojects(e.g.whennew development methods are used), a formal risk-management process, supported bywelldevelopedmethods,isrequired.Theresultsofthisfirstprocessstepare:

·Risk-managementtargets,methodsandtools;

·Adefinedtimeframefortheanalysiscycles(e.g.onceamonth);

·Adefinitionofriskcategorieswhicharenottobeconsidered(e.g.marketingrisks);

·Risk-managementrolesandtasks;

·Communicationmechanismsandreports;and

·projectstakeholdersandtheirexpectationsvis-à-vistheprojectresults.

In particular, it is the consideration given to stakeholders that distinguishesRiskit fromother risk-management methods. This concept is based on the idea that differentstakeholders have different goals and expectations for the project. Consequently, thesecondprocessstep,“Goalreview”,examinestheproject targetsandformulatestheminasmeasurableaformaspossible.

It also analyses which goals are how important for which stakeholder. Goals andstakeholders place a crucial role in the “Risk analysis” step. Each risk is analyzed todetermineitsimpactsontheprojectgoals.Theseimpactsaredescribedinasmeasurableaformaspossible(e.g.projectdelayedbythreemonths=budgetexceededby$50,000).Since the “Goal review” step defines in advance which goal is important for whichstakeholder, it is thenpossible toestimatewhowill incur the largest loss ifa riskeventoccurs.Theseanalysesarealsoofbenefitwhenspecifyingmeasures.

Risk-AnalysisMethods

Oneofthefirststepsinariskanalysisistodescribetheriskindetail.Anexampleformforthispurposecanbefoundin[Doro96].Basedonthisform,ariskdescriptioncontainsthefollowinginformation,someofwhichisnotgathereduntilthecontrolmeasuresorthemonitoringphaseisplanned:

·Uniquerisktitle,

·Identificationdate,

·Formaldescriptionoftheriskusingriskfactor,riskeventandriskeffect,

·Contextdescriptioncontainingadditionalinformationintextform,

·Personwhoidentifiedtherisk,

·Priority,

·Probabilityofariskeventoccurring,

·Degreeofimpact(riskeffect),

·Timeatwhichtheriskeventislikelytooccuroratwhichmeasureshavetobetaken,

·Classification,

·Responsibleperson,

·Strategyaimedatreducingtheprobabilityoftheriskeventoccurringoratavoidingtherisk,

·Actionplanshouldtheriskeventoccur,

·Statusanddatewhenthestatuswaslastrecorded,

·Personwhoacceptedtherisk,e.g.projectmanager,

·Conclusiondateand

·Reasonforconclusion.

Theriskscanbeprioritizedbasedonqualitativecriteriawiththehelpofariskportfolio.Withthismethod,theprobabilityoftheriskeventoccurringandthedegreeofimpactareratedas“low”,“medium”or“high”.Thus,threeprioritycategoriescanbedefined:

·High-priority risks (Aquadrant)are thosewhichare ratedas“high”foroneparameterandatleast“medium”fortheother;

·Low-priority risks (Cquadrant) are those rated as “low” foroneparameter and at themost “medium” for the other; and · the other risks are assigned medium priority (Bquadrant).

CHAPTER-4

CurrentResearchonSystematicRiskManagement

4.1.AdditionsofnewfeaturestomanageRisksThetactical,bottom-upapproachestoanalyzingnumerousriskstatementshave,intoday’scomplex,distributedprogramsandenvironments,ledtopartialviewsofthe“bigpicture”and inefficient allocation of scarce resources. Many risk management processes haveturned into time and resource-intensive bureaucratic nightmares that, in the end, do notprovidetherightinformation.TheSEIrecognizedthatsomethingelseclearlywasneededto return risk management to its original purpose—supporting effective managementdecisionsthatleadtoprogramsuccess.

Current research is focused on systemic risk management—top-down, system-orientedanalysesofriskinrelationtoprogramobjectives—whichisbettersuitedtomanagingriskindistributedenvironments.Thisresearchhasbroughtaboutthedevelopmentofasuiteofmethods—Mosaic—thatcanbeusedtomanageriskandopportunityacrossthelifecycleand supply chain, enabling decision makers to more efficiently engage in the riskmanagementprocess,navigating throughabroad tradeoffspace(includingperformance,reliability, safety, and security considerations, amongothers) and strategically allocatingtheirlimitedresourceswhenandwheretheyareneededthemost.

Wehavefoundsystemicapproachestobebettersuitedformanagingriskandopportunityin distributed environments. In contrast to the bottom-up analyses employed in tacticalriskmanagement,systemicapproachesincorporatetop-down,system-orientedanalysesofriskinrelationtoprogramobjectives.[172]

Needfortheresearch

Numerousstudieshaveidentifiedriskcontributorsinsoftware-intensiveprojects.Wethenaggregatedandsummarizedtheserisks.

Additionalriskissues

Formoderate- and high-complexity development projects, several issues can contributesignificantlytoincreasedcostsandscheduleslippage,suchas

usingaperformance-dominatedrequirementsgenerationprocessthatbeginsbeforeyouformallystartyourdevelopmentprocess,

starting aprojectwith abudget and schedule that is inadequate for thedesiredperformancelevel,

usingaperformance-drivendesignanddevelopmentprocess,

establishing a design that is near the feasible limit of achievable performance(where themagnitudes of the first and second derivatives of costwith respect toperformancecanbeverylarge),

beingoverlyoptimisticinassessingthelimitsofperformanceachievableforagivenbudgetandschedule,and

Making major project design decisions before the relationship between cost,performance,andscheduleisunderstood.Eachoftheseitemsgenerallycontributesto

overoptimisminestablishingandestimatingadequateprojectcostandschedule,

underestimationofcostandschedulerisk,and

Aneventualincreaseinprojectcostandscheduleduringdevelopment.

Immatureoruntrieddesign,process,ortechnologiesselected

Inadequateworkplansorconfigurationcontrol

Inappropriatemethodsortoolselectionorinaccuratemetrics

Poortraining

Inadequateorexcessivedocumentationorreviewprocess

Legalorcontractualissues(suchaslitigation,malpractice,ownership)

Obsolescence(includesexcessiveschedulelength)

Unanticipateddifficultieswithsubcontracteditems

Unanticipatedmaintenanceand/orsupportcosts

High-risk designs can occur when the buyer and seller focus primarily on increasedperformance, and thus it comes to dominate the resulting design, even if it increasesproject riskaswellascostandschedule.The situation ismadeevenworsebecause therisk level in complex projects is routinely underestimated, often due to human andorganizationalbehavioralissuesthataredifficulttosolveorevenidentify.[173]

Recentadvancements

We discuss below five recent contributions in the area. They primarily propose riskanalysismethodologies,andnotacompleteriskmanagementframework.

Foo and Murugananthan’s Approach: Foo and Murugananthan (2000) proposed aquestionnaire-basedapproachforanalyzingriskstoprovidetheirquantitativeassessment.Their approach can be used to quantify risk elements, and use them to estimate anormalized value of the overall project risk. Their model, called the software riskassessmentmodel (SRAM), is based on the use of situational factors to predict projectrisks. In other words, risk assessment in this model is dependent on the nature of theproject,andthesituationsfacingit.

Their model is questionnaire based, and analyzes risks to provide their quantitativeassessment.Intheirmodel,theyconsiderninecriticalriskelements:softwarecomplexity,project staff, targeted reliability, product requirements, estimation methodology,monitoring methodology, development process adopted, usability of developmentsoftware, and tools. Thereafter, they frame a list of questions for the risk assessor, byproviding threechoices for eachof theabovecritical riskelements.Theanswersof theassessorsareassessed,andsortedaccordingtotheirincreasingrisk-levels.

Deursen and Kuipers’ Approach: Deursen and Kuipers (2003) proposed a novel riskassessmentmethodologybyidentifyingthedifferentprimaryfacts,andsecondaryfactsin

aproject.Theprimaryfactsareobtainedbyanalyzingthesystem,andthesecondaryfactsareobtainedbyinterviewingdifferentstakeholders,reviewingcontractdocuments,projectplans,requirementsspecifications,anddesigndocuments.Finally, theprimaryfacts,andthe secondary facts are taken in tandem, and compared to observe whether the risksperceived from both the angles are consistent with each other. This software riskassessment methodology is different from the traditional extremes of product riskmanagement, and process riskmanagement.The advantage of it is that it builds on theadvantages of both the above-mentioned extremes to resolve risks having conflictingviewpointsamongststakeholders.

Roy’s Approach: Roy (2004) developed the ProRisk management framework byextending theAS/NZS4350standard. It categorizes the riskmanagementactivities intothebusinessdomain,andtheoperationaldomain.Itperformsdifferentactivitiessuchas,identifying thestakeholders, identifying therisks factors,constructinga risk-freemodel,calibrating therisk-freemodel,estimating theprobabilitiesofriskevents,evaluating thecombinedvaluesofrisk,developingactionplans,andmonitoringtheprogress.

The ProRisk framework identifies two important focal points for risk management inprojects: Business domain: Focuses on the organization and the project domainperspectives.Itidentifiesthebusinessparametersoftheenvironmentinwhichtheprojectisconducted.

Operational domain: It focuses on the formal modeling of different aspects of riskmanagement in the project. Typical activities constituting the operational domain aremeasurementofriskvaluesperformingriskassessments,identifying,andproposingactionplansformitigatingrisks,implementingthem,andcontinuouslymanagingthem.Tiwanaand Keil’s Approach: Recently, Tiwana, and Keil (2004) developed a handy softwaredevelopment risk assessment tool (methodology) that project managers could use toquickly assess some of the important project risks, and their effects. This tool, and thequestionsinitweredevelopedasaresultofriskmanagementdatacollectedfromtheITmanagersof60companies.

The important achievement of this tool is that it can help in quickly assessing theimportantrisksthreateningaproject,insteadofdeployingafull-fledged,time,andbudgetconsuming riskmanagementmethodology.Misra et al’s Approach:Misra et al. (2005)havealsoproposedanapproachforsoftwareengineeringriskmanagement.Thisapproachcouldbeusedbyprojectmanagerstomodel,andcontrolrisksinsoftwareprojects.Thereare no similar approaches onmodeling software project risks in the existing pieces of

literature.

The approach is, thus, novel to the area of software riskmanagement. The approach ishelpful to projectmanagers for performingmeans-end analysis, thereby uncovering thestructural origin of risks in a project, and how the root-causes of such risks can becontrolledfromtheearlystagesof theprojects.Thoughsomeattempthasbeenmadetomodel riskmanagement in enterprise information systems using conventionalmodelingtechniques, like data flow diagrams, andUML, the previousworks have analyzed, andmodeled the same just by addressing “what” a process is like. However, they do notaddress“why”theprocessisthewayitis.

Our proposed approach addresses this limitation of the existing software project riskmanagement models by exploring the strategic dependencies between the actors of aproject,andanalyzingthemotivations,intents,andrationalesbehindthedifferententities,andactivitiesinaproject.Theconceptofstrategicdependenciesbetweentheactorsofaprojectisnotnew.AgoodreviewoftheconceptcanbefoundinChungetal.(2000).Thisapproachisrestrictedtoprovidingamethodologythatonecoulduseintheexistingriskmanagement lifecyclemodels to analyze, and uncover the structural origin of the risks,andcontroltherisksfromtheearlyphasesofaproject.[174,175,176]

4.2.IndustriestalksaboutRiskManagementTheAccenturestudy

Oneofthelargestriskmanagementsurveysofitskind,theAccenture2011GlobalRiskManagement Study finds that advanced risk management capabilities are high on theexecutive agenda and now seen as a critical business driver and source of sustainedgrowth and long-term competitive advantage. The Accenture 2011 Global RiskManagementStudy isbasedonaquantitativesurveyofexecutives from397 companiesacrosstenindustries.Allrespondents’were-levelexecutivesinvolvedinriskmanagementdecisions at their companies; organizations were split primarily among Europe, NorthAmerica,LatinAmericaandAsiaPacific.

Different-sized companieswere also represented: about half the companies representedhadannualrevenuesoverUS$5billion;one-fourthhadrevenuesbetweenUS$1billionandUS$5 billion; the remaining quarter had revenues between US$500 million and US$1

billion. In addition to the quantitative survey, additional in-depth interviews wereconductedwith a number ofexecutiveswhoseviews are alsorepresented in the surveyfindings.Theseinterviewsenabledustoprobemanyofthekeyissuesandfurtherexplorelessons and perspectives of some of the leading companies. Reflections from theseexecutivesareincludedthroughoutthisreport.

Riskmanagementasasourceofcompetitiveadvantagebeyond the immediatepressuresofglobalmarkets,moredemandingcustomersanddramaticindustrychangeisagrowingrecognitionthatcompanieshaveanopportunitytodrivecompetitiveadvantagefromtheirriskmanagementcapabilities,enabling long-termprofitablegrowthand sustained futureprofitability.Thismeans that riskmanagement at the top-performing companies is nowmorecloselyintegratedwithstrategicplanningandisconductedproactively,withaneyeonhowsuchcapabilitiesmighthelpacompanymoveintonewmarkets fasterorpursueotherevolvinggrowthstrategies.

At its best, risk management is a matter of balance—the balance between company’sappetiteforrisksanditsabilitytomanagethem.Anadvancedriskmanagementcapabilityincludes the ability to understand and manage what Accenture calls “risk-bearingcapacity”—acompany’scapacity to takeonnewopportunities (whichbydefinitionwillincludeashareofrisk),aswellasitsabilitytowithstandtheeconomicshocksshouldthoserisksbecome issues.Neither toocautiousnor too reckless, thebest companiesuse theirriskmanagementcapabilitiestoadjusteithertheircapacityortheirappetitetomakemoreprudent—andultimatelysuccessful—investmentdecisions.

As theGlobalRiskManager for aEuropeanproductsmanufacturernoted in a researchinterview,“Key riskperformance indicatorsandspecific, focused risk analyses are nowmoreoften included in investmentandstrategicdecisions.”TheChiefRiskOfficerofaglobalreinsurancecompanytoldusthatthefirm’senterpriseriskmanagementframework“isreallytailoredtothecompanytoturnitintocompetitiveadvantage.”

•Thetypesofriskstowhichcompaniesareexposed,aswellastheirseverity,aregrowingaccording to surveyed executives. Companies are increasingly concerned about thespectrumofrisks—fromsupplychaintooperationstoregulationto reputation.Financialfraudandcrimeareontherise.

• Despite major investments to improve risk capabilities, critical exposures persist,especially given companies’ inability to improve their risk measurement capabilities

sufficiently.Riskmanagementneedstosupportpositivebusinessgrowth,notonlyprotectagainstnegativeoccurrences,socompaniesneedabetterwaytoassesstheirrisk-bearingcapacity.

•Organizational silos and outdated information systems preventmany enterprises fromadequately sharing information that could mitigate risks more effectively. Betterorganizational structures and underpinning systems are essential if the challenge ofintegrationistobemet.

•Performancegapsexistbetweencompanies’expectationsforriskmanagementandwhatisactuallyachieved.Executiveswantriskmanagementtobeadriverforsustainedfutureprofitability,andtheyunderstandtheimportanceofinfusingariskculturethroughouttheirorganization,buttoofewcompaniesareachievingthosegoals.

•Costpressurescontinueunabated—requiringeffectivemanagementbothintermsofcostofoperationsand in termsof investmentdecisions—thoughotherconcernsare risingaswell.

Executivesseeagrowingneedtoalignriskmanagementwiththeoverallbusinessstrategy,respond to regulatory demands and improve their modeling and analytics capabilities.LearningfromtheRiskMastersSomecompaniesare leading thewaywhen itcomes todrivingcompetitiveadvantagefromtheirriskmanagementcapabilities.

TheAccenture 2011Global RiskManagement Study identified a set of RiskMasters—about 10 percent of the almost 400companies surveyed—whose risk managementcapabilities are superior to their peer set. Accenture believes that by studying theRiskMasters and learning how they have effectively advanced their risk managementcapabilities,organizations can gain practical insights as they look to enhance their ownriskmanagementprocesses,technologiesandtalent.

The advanced capabilities of the Risk Masters stands a set of directional goals andworkingexamplesforallcompaniesthatseektogeneratecompetitiveadvantageandhighperformance from their risk management strategies and capabilities. Based on surveyanalysis, the followingriskmanagement capabilities raised to the topwhen it comes tomasteringanewgenerationofriskmanagement:

• Look to create shareholder value from riskmanagement. RiskMasters are especiallyadeptatcreatingprocessesandmechanismsthatlinkrisktobusinessperformance.

• Involve the riskorganization inkeydecision-making processes.The riskmanagementorganizationneedstobeincludedinactivitiessuchasstrategicplanning,objectivesetting

andincentives,financingdecisionsandperformancemanagementprocesses.

•Improvethesophisticationofmeasurement,modelingandanalyticstoanticipaterisksinan increasinglycomplexenvironment.RiskMastersaremore likely tomeasure a fullerspectrumofrisktypes,andtheyhaveahighercommitmenttoanalyticsandriskmodeling.

•Gobeyondacompliancemindsetofriskmanagementtodelivermorecompletebusinesssolutions that drive competitive differentiation. Top-performing companies are better atmanaging regulation and compliance in a way that also delivers better businessperformance. Risk Masters are also better at developing relationships with regulatoryagencies.

• Integrate risk management capabilities across business units and organizationalstructures.MuchhigherpercentagesofRiskMastersexcelatthe integrationrequiredforeffective risk management, something that requires a commitment to evolvingorganizationalcapabilitiesoveramulti-yearprogramofchange.

• Establish a dedicated, C-level risk executive with oversight and visibility across thebusiness. Top performers separate themselves from the pack by having in place adedicated risk executive with sufficient visibility and leverage to influence riskmanagementcapabilitiesacrosstheentireorganization.

• Infuse risk awareness across the organizational culture. It is vital to have in placemechanismstocreateanddistributedmorebroadlyacross theorganizationanawarenessofriskexposure,detailedtrainingandthemeanstomitigaterisks.

•Investincontinuousimprovement.Riskmanagementisanongoing,evolvingcapability.Theworldchangesrapidlyandcompaniesmustbenimbleintermsofstayingaheadofthecurvewhenitcomestomeetingtherisksandchallengesahead. Inaworldofcontinueddramatic change—economic, marketplace, business and technological—companiescommitted to driving shareholder value and strategic business outputs from their riskmanagementcapabilitieswillbebetterplacedtoachievelong-termcompetitiveadvantageandhighperformance.[177]

Futureriskmanagementchallenges

Reducingcosts

AligningwiththeoverallbusinessstrategyImplementingregulatorydemandsImprovingrisk management and modeling Data management(availability, consistency,

organization)Developing a risk culture Integrating Risk and Finance information andprocesseswithintheorganizationRetainingandsourcingresourcesandtalentDevelopingrisk metrics Availability of comprehensive technological solutions Raising riskmanagementasapriorityforexecutiveleadershipImprovingreportingCollaboratingwithbusinessunits Identifying riskmanagementvaluepropositionExpanding theChiefRiskOfficer’sroleandviewofrisk.

Excessive, immature, unrealistic, orunstable requirements.Prior to starting this project,thisriskwasoneofthemainreasonsTRW’slargesoftware-intensiveprojectsexperiencedcostoverrunsandscheduleslips.Toaddressthismajorriskarea,weusedtheTRWAdaProcess Model. With this process model, you specify not just your current projectrequirements,butplan for their likelydirectionsofgrowthandchange.Themodel thenusesParnas’ informationhiding techniques18 tomodularize the software architecture tofacilitateanticipatedchanges.

Severalotherthingsalsohelpeduscontainthepotentialimpactofrequirementschanges:awell-defined and agreed-upon change control process, metrics to track requirementsgrowthandstability,andallocatingcapabilitiestothevariousincrements.

Lackofuserinvolvement.

Priortothestartofthisproject,TRWhadextensivecustomerinvolvement,butlittleuserinvolvement,andthuslargeprojectswithhuman-machineinterfacesoftenfailed tomeetuser expectations. To address this risk area, the project used extensive prototyping anddemonstrated functional capabilities as part of the early reviews (such as designwalkthroughs).Thisprototypeevolvedintotheoperationalsystem.

Thus,unliketraditionalpaperdesignreviews,userscouldseethedisplaysandinteractionstobebuilt intothefinalsystembeforeCDRwascompleted.Tobuild flexibility into thesystem,wedevelopedanoperationalcapability tomodifydisplay formats.Thisprocessmodel also included a longer design phase to ensure that there was sufficient time toprototypefunctionalcapabilitiesandtogetuserconcurrence.

The usual schedule problems that occur during integration did not happen because theactual system integration startedduring theprototypingactivities.TRWworkedwith theacquisitioncustomerandendusers inworkinggroups todevelop thedetailsofdisplaysandalgorithms.Therepresentativeshadtheauthoritytomaketechnicaldecisions.

Theseworkinggroupswerekeys.Thesystemwasverycomplex,andearlyanalysesand

decisions resolved many users’ concerns. Waiting until the traditional end of thedevelopment cycle to-do the analysis and make decisions to incorporate newenhancementswouldhaveledtobothcostgrowthandscheduleslippage—notonlytothedevelopmenteffort,but to thosedependingon thesystembeingoperationalbyacertaindate.

Underestimationofprojectcomplexity

Based on previous experience, we knew that changes would occur throughout thedevelopment process. We selected thevTRW Adam Process Model because itsincremental,evolutionary approachwould help us address the project’s complexity anddynamic nature. The fall of thevBerlinWall, for example, had a major impact on thesystem’soperationalconceptandrequirements.

Performanceshortfalls.

Becausewehadvery tightperformance requirements,we addressed this risk during theproposalpreparationphase. In the systemsengineeringarea,performancemodelingwasinitiatedat thebeginningof theproject.As thedesignevolved, themodelwasupdated;whenpotentialproblemareaswereidentified, theyweretransmittedtothere.Inadditiontotheperformancemodelingactivities,theactualsoftwarearchitectureskeletonwasbuiltusing the network architecture services, and executed with stubs to simulate theprocessing.

Sincethesoftwarearchitectureskeletonwasbuiltusingacode-generationtool,itwaseasyto change the architecture quickly and with minimal impact to the ongoingdesign/implementationwork.Thisletusexaminedifferenthardwareandsoftwaredesignalternativesveryearly,whichminimizedthepotentialcostandscheduleimpactthatmighthaveoccurredifatraditionaldevelopmentapproachwasused.Forexample,many typesofperformanceproblemscannotbeidentifieduntilthesystemisintegrated,whichusuallyoccursafter coding and unit level testing arecomplete.Again, sincewe started systemintegrationduringthedesignphase,wecouldaddressperformanceissuesearly.

Unrealisticcostorscheduleestimates.

Weconductedseveraltrade-offstudiesusingtheAdamCocooncostmodel todetermineworkablecombinationoffunctionality,budget,andschedule.

Ineffectiveprojectmanagement

Fromthestart,wehadseveraldifferenttypesofperiodicreviewsinvolvingeveryonefrom

thehands-onengineer totheprojectmanager.These includedreviewsofcost, schedule,technology, systems engineering status, software engineering status, and risk reviewboards. These reviews, together with the use of metrics, ensured that we identifiedpotentialproblemsearlyandhandledthembeforetheyaffectedtheprojectsignificantly.

Ineffectiveintegration,assemblyandtest,qualitycontrol,andsoon

WeusedAdpackagespecificationsduringthedesignphasetoconsistency-checksoftwareinterfaces, thusaccomplishingsignificant integration prior to coding rather thanwaitinguntilintegrationtesting,whichcostsmore.

Immatureoruntrieddesign,processes,ortechnologies

TheTRWAdamProcessModelwasanewconcept for thecustomer.Togain customeracceptance,wemetseveraltimestodiscussitandtheimplementationapproach.Toensurethat the process model was working, we monitored metrics throughout the projectdevelopmentphase.Forexample,wemodifiedthedevelopmentprocessslightlywhenwemoved responsibility for system integration from the independent test group to thesoftware development group. This increased efficiency during the prototyping andintegration activities and contributed to developers’ pride of ownership when theirsoftwarewasintegratedintothesystem.

Inadequateworkplansorconfigurationcontrol

Based on TRW’s prior experience, we recognized that detailed plans and solidconfiguration control were very important to project success. We thus developed,maintained, and used detailed work plans and configuration management proceduresthroughout the development cycle.One of the key configuration control toolswas thehierarchical tested, which automated version control and the software change ordertracking process. Quality assurance personnel conducted periodic audits of the variousconfigurationstoensureconfigurationcontrolwasmaintainedfromthebeginningof theprojecttocompletionoftheoperationalsystem.

Inappropriatemethodsortoolselectionorinaccuratemetrics

Weevaluated these ofmetrics throughout the project.We tailored the set ofmetrics toinsure that it was useful for trend analysis and eliminated extraneous or outdatedinformationtoreducecostanddocumentationburdens.

Poortraining

In 1987, theDoddAdmandatewas fairly new and, becauseAdowa’s a new language,

TRWdidnothavemanyAdamdevelopers.Priortotheprojectcontractaward,TRWsetupAdamlanguagetrainingformorethan100people.TRWsetupadditional trainingforsoftware engineers, including integrators and testers, on the Rational hardwaredevelopment environment. We also had attaining plan that tracked and identified therequiredandsuggestedtrainingforeachsoftwareengineerontheproject.

Inadequateorexcessivedocumentationorreviewprocess

Dataitemdescriptionsweretailoredpriortothecontractawardandthroughoutthevariousprojectphases.Theminimizedredundancyhelpedreducethedocumentationthathadtobegenerated,maintained,andreviewed.Earlyintheproject,customerteammembersmadenumerous comments on the many products they reviewed. These comments were thenanalyzed,categorized,andprioritizedbythecommentators.Wegavethemostattentiontothe higher priority comments. Meetings(which included commentators) were held toresolvecommentsandincorporateagreeduponchanges.Thiseliminatedseveralcyclesofcomments and revisions that usually occur when there is no dialogue between thecommentatoranddocument author.Legal or contractual issues. Thesedid not apply onthisproject.

Obsolescence

Available technologychangedatanacceleratingpaceover thecourseof theprojectandbothhardwareandsoftwareCOTSbecameobsoletemorequicklythanwehadpreviouslyexperienced. Project and vendor personnel worked closely together, and the vendorsprovidedearlynoticewhenaproductwasplannedforupgradeorobsolescence.Whenwelearnedofeitheraproduct’srevisionorits impendingobsolescence,wemanaged itasarisk item.Thechangeswere analyzed to determine if the systemwould be affected.Wethenprototypedtherevisedorreplacementproductandintegrateditwiththesystem.Wedid this off-line and did not change the software baseline until the product had beenthoroughlyprototypedandwewereconfidentitcouldbereplaced.Thisrequiredchangesto the application code on numerous occasions, but if and when the new product wasplacedintothesystem,itwasaplannedactivity.

Unanticipateddifficultieswithsubcontracteditems

Duringtheprojectdevelopmentphase,weassessedsubcontracteditemsfromaparticularvendortoberiskybecauseofthevendor’squestionable“financialhealth.”Weidentifiedthe vendor’s financial status as a risk item and developed and implemented a risk

mitigationplan.Thisplanincludedresearchtodetermineiftherewereanyothervendorswhocouldsupporttheproject’srequirements.Whenwedeterminedthatthiswasnotthecase, we initiated discussions with the vendor to start an escrow account for all theengineering informationandcopiesof theirsoftwarecode, incase theycouldno longersupporttheproject’sneeds.Thevendorisnowstrongerfinanciallyandtheescrowaccountisnolongernecessary.

Unanticipatedmaintenanceand/orsupportcosts

Maintenancecostsgrewat fasterpace thanweoriginallyplanneddue tochanges in thevendor cost rate structures, product changes, and hardware upgrades. We negotiatedchangeswiththevendorstominimizetheimpactofthesecostsandworkedoutmutuallybeneficialterms.[178]

PeerReviews

Peer reviews involvedmeetingsanddiscussionswithriskmanagementpractitionersandprovided some evaluation of the PMRAmethod against their personal knowledge andexperiences.Theyincluded:

•One-on-onediscussionswithariskmanagementexpertfromUKandariskmanagementpractitionerfromamajorPolishsoftwarehouse

•University seminars for software engineering professionals, where some parts of themethodwerepresented,

•Presentationsatseveralnationalandinternationalconferencesandfollow-ontalkswithriskmanagementprofessionalsfrombothindustryandacademia,

•RiskidentificationworkshopinaPolishsoftwaredevelopmentcompany.

Theone-to-onediscussionswereprecededbythepresentationofthePMRAmethodandtheRiskGuidesupportingtooltotheexperts,afterwhichtheywereaskedtoexpresstheiropinion.Bothpractitionersconfirmedthevalidityoftheassumedriskassessmentprocessand the scope of the tool support. The UK expert appreciated particularly the riskidentificationtechniques,expressinghoweversomedoubtsaboutthepossiblelowqualityof referential processmodels can impede the risk identification.ThePolish practitionerassessed highly the team-oriented approach to the risk assessment, which he had beenusingsuccessfullyinhisindustrialsoftwareprojects.HealsojudgedaccuratethescopeoftheriskassessmentreportsandthefeaturesoftheRiskGuidetool.

Several seminars given at the Gdansk University of Technology during the researchprovidedsomeapprovaloftheworktowardsthemethoddefinitionaswellaspointedoutsomeissuestobeconsideredforfurtherresearch.Oneofthemostimportantsuggestionsconcernedtheeconomicprofitabilityoftheriskmanagement,whichmustnotbeignoredwhilebuildingholisticmethod.Toaddressthisissue,themethodscalabilitywasseriouslytackled, which resulted in a multi-level approach to process modeling, the RiskKnowledgeBase tailoring,wide selection of risk identification and analysis techniques,andthecustomizableriskassessmentprocess.

The conference presentations on themethod attained some interest fromboth academiaand industry and resulted in severalmeetingswith software development professionals.Theyhaveappreciated thepracticalaspectsof themethodandsomeof themhaveevenexpressedwillingnesstousethemethodandtheRiskGuidetool in theirprojects.In theend,however,theyhavenotretainedtheirinterestandthemethodwasnottransferredtotheindustrythisway.

AriskidentificationworkshopheldatoneofthePolishsoftwaredevelopmentcompaniesprovided great feedback on the method. The workshop was related to a real softwareproject, which aimed at developing a GIS system to support management of a heatgeneration and distribution infrastructure in one of the major cities in Poland. Theparticipantswereabletoidentifyabout20riskstotheirprojectandcommittedtocontinuewith riskmanagement after theworkshop. Some interesting participants’ opinionswerealsogathered,whichresultedinmajor improvements to themethodconcerning theRiskKnowledgeBasestructureandtheriskcommunicationsecurity[Mileretal.2002].

The results of peer reviews summarized above can be considered a preliminaryconfirmationofthemethod’sapplicabilityandpracticality.Thepractitioners’interestandopinionssuggesttheyperceivethemethodasusefulinreal-lifesoftwareprojects.[179]

MajorRisksintheSoftwareDevelopmentPhaseswithMitigationsteps

1.RiskduetocomplexityoftheprojectMitigation

Theproject shouldbebrokendown intomajormodules.So that the complexity canbe

overcome.

RequirementSpecificationshouldbeclearandunambiguous.

2.Riskduetoavailabilityofresourcepersonhavingcommandonthetechnologytobeused?

Mitigation

ThisRiskcanonlybecoveredbysearchingtherightpersonhavingthecommandonthetechnologytobeused.

3. Risk due to skills / competency of the resource person on the technology to beused?

Mitigation

Skillsandcompetencyofthepersonshouldbehigh.

4.Riskduetoteamharmonyandworkingrelationship.

Mitigation

1.DifferentHRM techniques should be practiced to develop harmony among the teammembers.

2.Projectteammaybeformulatedinsuchawaythat.

5.Riskduetochangeinrequirements(MinororMajor)?

Mitigation

1.UsingProperPerformaorpatterntogetrequirementsfromtheuser.

2.Feasibilityofthechangedrequirementshouldbemeasure.

6.Riskduetolackofclient/user/Customerknowledge?

Mitigation

1.IfClienthasnotmuchknowledgeaboutsystemtobebuiltthenanyotherpersonfromthatorganizationshouldbeincontact.

2.Clientshouldbeinformedproperlyaboutthetechnologyandthesystem.

7.Riskexpectedduetoflexibilityornonflexibilityofschedule?

Mitigation

TomakeScheduleinsuchawaythatthereshouldbeflexiblegapsineachphasesothatifsomephaseisdetractfromtheschedulethenthisgapmaynotlettheotherphaseaffect.

375TahirAbdullah,AhmedMateen,AhsanRazaSattarandTasleemMustafa

8.Riskexpectedduetolowlevelfinancialjustification?

Mitigation

BenefitCostAnalysisorsomeotherCostandbenefitanalysistechniqueshouldbeusedtocalculatethebenefitsfromtheproject.

9.Riskexpectedduetoignoranceofnon-functionalrequirements?

Mitigation

Performaforrequirementgatheringshouldbeperfectenoughtocapturethenonfunctionalrequirements asmaximumaspossible andall thedocuments regardingprevious system(EithermanualorComputerized)shouldbecollected.

10.Risksduetocomplexdesignofsoftware?

Mitigation

1.ComplexAlgorithmsshouldbebrokendownintosmallchunks.

2.FlowChartsofthealgorithmsshouldbedefinedandmappedcarefully.

11.Riskduetouseofreusablecomponents?

Mitigation

SelectionofreusableComponentsshouldbemadecarefully.

12.Risksduetolessexpertiseonreusablecomponents?

Mitigation

Whileselectingthereusablecomponent,itshouldbenotedcarefullythatitiscompatiblewiththeothermodulesusedinprojectanditmightnotcreatedotherambiguitiesduringdevelopment.

13.Riskduetolesscommandonprogramminglanguageandtoolstobeused?

Mitigation

1.Shouldchoosethelanguageonwhichtheexpertiseismore.

2.Shouldtakeproperhelpfromsomeseniorpersons.

14.Risksduetomissingcomments?

Mitigation

Propercommentsshouldbeaddedduringfunction,classesandothermajormodules.

15.Riskduetotesting?

Mitigation

1.Softwareshouldbetestedaccordingtothecomplexityandnatureofproject.

2.ThistestinglevelshouldbedefinedattheRequirementspecificationtime.

16.Riskduetorestructuringofthesitewheresoftwareistobeinstalled?

Mitigation

DesignofNewStructureofthesiteshouldbeplannedcarefullykeepingviewofneedoftherestructureraccordingtotheplace.[180,181,182,12,183,184]

Majorfindings

TheAccenture 2011Global RiskManagement Study is one of the largest risk surveysconducted,withalmost400executivessurveyedacross10majorindustriesandallmajorgeographies.Thereportonthesurveyfindingsisinthreeparts:

Part 1 details survey results related to the increased emphasis being placed on riskmanagementbytoday’sexecutives.

Part 2 discusses the challenges ahead as seen through the eyes of risk managementexecutives.

Part3providesmoredetailabouthowRiskMastersdiffer fromtheirpeersandwhatallcompaniesmightdotoemulatetheirriskmanagementstrategiesandcapabilities.

The study began with a set of hypotheses about the increasingly complex businessenvironmentand thedistinctive riskmanagementcapabilities thatneed tobeenplace tosurviveandthriveinthatenvironment.Thesehypothesesincluded:

• Increasing volatility and growing complexity make risk critical and central to allindustriesoperatingintoday’sbusinessworld.

• Although heightened awareness of the importance of risk exists, critical exposurespersistandthebenefitsofenhancedriskcapabilitieshaveyettoberealized.

• Top-performing organizations transform risk management into a value-enhancingcapabilitywhereriskisusedascompetitivedifferentiator.

•Failuretolinkriskmanagementtogrowthandvaluemeansleavingmoneyonthetable,and,consequently,thefailuretoachievehighperformance.Eachofthesehypotheseswasborneoutbythesurveyfindings.Asseeninthereport,executivesareacutelyawareoftheimportance of advanced risk management both to meet pressing needs and to createadvantageinthefuture.Manychallengesremain,butforthemostpart,mostoftheseniorexecutives across all industries are prepared to invest inwhat it takes to protect theircustomer relationships, ensure compliance and advance their competitive marketpositions.

Results from theAccenture2011GlobalRiskManagementStudy support the followingkey insights related to the heightened importance of risk management capabilities inmeetingtoday’sbusinesschallengesandopportunities.

Increasingvolatilityandgrowingcomplexitymakeriskmanagementcentralandstrategicto all industries .More than 80 percent of companies surveyed, across all industries,consider their risk area to be a key management function that helps them deal withmarketplacevolatilityandorganizationalcomplexity.Eighty-sixpercentidentifytheriskmanagement function as a driver to help them deal effectively with the increasingvolatility of the economic and financial environment; 83 percent see the function asdrivingbettermanagementoforganizationalcomplexity. Interestingly, financialservicesfirms(banking and capital markets) and insurance companies were only slightly morelikely to focus on risk management as a support for managing external volatility—reinforcing the view that riskmanagement is increasingly important across all industrysegments.

Riskinsight1

IncreasingvolatilityandgrowingcomplexitymakeriskmanagementcentralandstrategictoallindustriesForalmostallcompanies,riskmanagementisahigherprioritytodaythanitwas twoyearsago.Ninety-eightpercentof respondents indicated thiswas so, and60percentindicateditwasso“togreatextent.”Thatnumberwashigherforfinancialservicesfirms(70percent)andinsurancecompanies(69percent).Changingregulationsandfallout

from the economic crisis are clearly drivers behind higher-than-average responses fortheseindustries—butnottheonlyones.AccordingtotheRiskDirectorofanAsiaPacificfinancial services firm, “Risk is a higher priority for us than two years ago becausebusinessandriskcomplexityarechanging—drivenbyregulation,competition,customerexpectations, technology, processes, environmental issues and new products, aswell asmacroeconomicandmarketfactors.

Businessandriskcomplexityarerisingfasterthanthecurrentriskmanagementfunctioncankeepup.Hence,wearenowenhancingourriskmanagementcapabilitiestenableourorganizationtokeeppacewiththosecomplexities.”

Fromageographic perspective, slightly fewer executives inNorthAmerica (53percent)state that risk managements a higher priority today “to a great extent” compared withEurope (62percent) andAsiaPacific (65 percent).This finding ismost likely due to thefact thatmanyNorthAmericancompanieshavebeen investing in riskmanagementasapriority for several years. However, leading practices and abilities to share riskmanagementlessonsareclearlymulti-directionalintoday’sglobalenvironment.

Allcompanies need to look bothEast andWest in seeking out important insights fromtoday’sbestcompanies.Perhapsnotsurprisingly,thebiggerthecompany,themorelikelyit considers risk a higher priority today than two years ago. Sixty-seven percent ofcompanieswith annual revenues overUS$5 billion stress risks a top priority comparedwith52percentofcompanieswithrevenuesunderUS$1billion.

One of the key differences between Risk Masters and their peer group shows upimmediatelyinthisfirstinsightaboutthenurturingoftheriskmanagementfunctionasameans to deal with marketplace challenges.(For more detail about risk managementmastery, see Part 3 of this report.) Sixty-nine percent of Risk Masters believe riskmanagementIsahigherpriorityfor theircompaniestoday than twoyearsago,comparedwith 59 percent of their peers. Sixty-four percent of RiskMasters recognize their riskmanagementorganization at thehighest levelof importance tomanaging the increasingvolatilityof theeconomicandfinancialenvironment,comparedwith35percentofnon-Risk Masters. And 52 percent of Risk Masters recognize their risk managementorganization as important to managing the growing complexity of their internalorganization,comparedtojust27percentoftheothercompanies.

In short, the Risk Masters acknowledge risk management as a key priority for theircompanies and plan and invest accordingly. As the Chief Risk Officer of one of thecompaniesinoursurveyputit,“Ahigh-qualityandefficientriskmanagementfunctionisamong the top strategic goals of the company, ranking second only to growth andprofitability.”

Beyond simply seeing risk managements a top priority, Risk Masters view the riskmanagementfunctionasamoreproactivepartnertothebusiness,helpingtodrivegrowthand sustained profitability. Almost all respondents felt that their risk managementcapabilities provide at least some source of competitive advantage, finding consistentacross industries. About half the companies surveyed(49 percent) see their riskorganizationasacriticaldriverforenablinglongtermprofitablegrowth;another42percentsawtheirriskmanagementcapabilitiesas“important”togrowth.Almostidenticalnumbers(48percent)saw riskmanagement as critical tosustained futureprofitability,withanother45percentbelievingittobe“important.”

Riskinsight2

Executivesseetheirriskmanagementcapabilitiesasimportanttofutureprofitabilityandlong-termgrowththesearehighpercentages.Putanotherway,91percentand93percentofexecutives, respectively,see the riskmanagement function as important or critical togrowth and profitability. The Risk Director for anAsia Pacific financial services firmstatesthisimportanceexplicitly:“Ourriskorganizationandfunctionswereestablishedtosupportandenableourorganizationtoachievestrategicgoalssuchassustainablegrowthand profitability, competitive advantages and capital management. Put simply, werecognizeriskasapartofthestrategicagenda.”

Fromanindustryperspective,retailersfindtheirriskmanagementfunctiontobeasourceof competitive advantage,with capabilities that includemoreefficient capital allocationandreductionsincostofcapital.At37percent,consumergoodsandservices is the leastlikely industry to believe the risk function is a source of competitive advantage and ofhigherperformancerelativetocompetitors.Bygenerallywidemargins,RiskMastersweresignificantly more likely to see the risk organization as a driver of several important

business benefits. For example, 67percent of RiskMasters hold their riskmanagementcapabilitiestobeadriverofsustainablefutureprofitabilitycomparedwith46percentoftheothers,a21pointdifference.Similargapswerefoundinotherbusinessbenefitstobederivedfromeffectiveriskmanagement:

• Reduced operational, credit or market losses: 74 percent of Risk Masters versus 34percentofothers(40pointdifference)

•Infusingariskcultureintheorganization:69percentversus36percent(33points)

•Positivecommentsfromanalysts:55percentversus23percent(32points)

•Managing reputation: 62percentversus 35 percent (27 points).As further support, thelinkbetweenriskmanagementandprofitabilityhas-beenvalidatedbyotherindependent,academic studies. A 2009 research initiative from the University of Gothenburg, forexample, found thatcredit riskmanagementhadappositive impact onprofitability forthcommercialbanksinthestudy.Thefindingsrevealed thatcredit riskmanagementhadapositive impact on profitability at all four banks studied. Capital adequacy ratio(CAR)contributed positively to banks ‘profitability as measured by return on equity(ROE),whilenon-performingloanratio(NPLR)showednegativeeffects.

As seen in the detailed discussion of risk mastery in Part 3, supporting growth andprofitabilitywilldependonanumberofadvancementsthatimprovetheriskmanagementfunction’s ability to be proactive and to achieve a more strategic reach. Our riskorganization and functions were established to support and enable our organization toachievestrategicgoalssuchassustainablegrowthandprofitability.[185]

4.3.OtherapproachestoRiskManagementThe approaches described above do not help in predicting the reliability of the finalproducts. Another class of researchers approached risk management from a productreliability viewpoint. They took a probabilistic approach for assessing software risk bymeasuring reliability of the products. Specifically, they do not solve the problem ofmanaging risks in project failure due to its inability to complete within the requiredbudget,andschedule.

Therefore, as mentioned before, in this article we intentionally omit discussing suchapproaches here, and limit the scope of this article to the discussions of project, andprocess risk management methodologies. However, for the sake of completeness, we

mention that some of the excellent works on product risk management (specifically,softwarereliability)canbefoundinKarunanithiandWhitley(1992),Lanning(1995),Lye(1995),andMusa(1998).[186,187]

Although software risk management is a daunting task, organizations that implementeffective processes proved to be successful, while those that fail in this effort will beunsuccessful.The nature of software projects createsmany risks thatmust bemanageddiligentlytoavoidthecommondrawbackofmanyprojects.

The perceptions and attitudes towards risk management activities compound difficultchallengesforimplementingariskmanagementstrategy.Formalriskmanagementprocessis recommended to manage complex issues associated with software developmentprojects.Many riskmanagement processes have been created to aid organizations, butintegratingtheprocessesintoorganizationswasnotsuccessful.Thetheoreticalaspectsofthe process must be reconciled with the practical challenges of the organization toimplementriskmanagementsuccessfully.Effectiveriskmanagementprocesswillsucceedbychangingtheorganizationalculturetomotivatetheindividual.Culturalchangesrequiretimeandrepetitionbeforetheyarefirmlyembeddedintotheorganization.[188,189]

Whiledevelopingthesolutionitwasimportanttounderstand,thatunlessthefundamentalsare resolved, the solutionwillneverbeefficientor accredited.Thecreative teamor thecreative personof anorganizationneeds to take control of these issues.Their expertisedoesnotlieintheriskmanagementordeployingaparticulartool,butmoreintheirdeepunderstanding and knowledge of business needs and the knack of developing variousmeasureswhichconcerntheproject.

Thinkingofanoldsaying,“failtoplan,then,plantofail”,organizationsneedtoovercomethisviciouscycleof“not”planningwithanopenmindandopeneyes.Allwhatcreativeteamneeds to accomplish is– simplify communication,build a teamspirit andprovideorganizationswith thoughtful culture ofworking towards achieving awin-win situation(Covey,1989).

Asdiscussedintheliterature,therearenumerousexternalriskstobemonitoredandfixed,sowhynotmakelife(withintheorganization)easierbycorrectingloop-holes,whichareinherentintheorganizationandinthehandsofpeoplewhocausethem.Consideringtherecommendations listed in the previous section, it is clearly understood that there aremany other issues needed to be resolved before coming up with a culture in an

organizationwhich helps in successful implementation of software projects.During theinitialresearchesonsoftwarefailure,itwasassumed that themain issue is lackof toolsandtechniquesbeingimplementedforriskmanagement,howeveritisnotthemainissue.Therearenumeroustoolsavailableataprojectteam’sdisposal;itistheirmaturitywhilechoosingthemwhichmakesadifferenceattheend.

The perceptions and outlooks towards risk management activities become the root oftough challenges encountered while applying numerous available risk managementstrategies.Duetotimeconstraints,itwasnoteasytoaccessthesolutiondevisedagainstasoftwareprojectsuccessmeasuresasdefinedbySoftwareEngineeringInstitute.Everyoneis aware of how a project can be defined as a success, although not every project issuccessful. However, analyzing cultural requirements of an organization and finding asolutionwastheaimofthestudy.

In order to conform to the cultural guidelines, the tool has to comply with ProjectManagement Standard. In order to develop a more effective tool for building RiskManagementCulture in a software setup, awider study is necessary.There are variousunderlying constraints which need to be addressed. Ngwenyama and Nielsen (n.d) areworkingwithanobjectiveandanalyzingtheassumptionsbasedonorganizationalculturethatareembeddedintheCMM(CapabilityMaturityModel–AmodeldevelopedbytheAmericanSoftwareEngineeringInstitute(SEI)incooperationwithMitreCorporationonNovember1986).

Future research should establish both convergence and variation between therecommended propositions and innumerable strategy measures of culture, throughpragmaticanalysis.Itishoweverchallengingtoestablishtheseaspectsofvalidity,asthecurrent scenario of software project validity of risk culture literature is hazy. Simplybecause in spite of extensive research, 1000s of books, tools and techniques on riskmanagement,culturemanagementandsoftwaremanagement, there is stillnotadefinitemeasure,whichisaccessibletothecorporateworld.Howeverasunderlinedintheabovementionedrecommendations, futureresearchersneedtoenlargesamplesize, in termsofthenumberoforganizationsmodeledand thenumberofemployeesstudiedwithineachorganization, inorder toboost thefindingsandincorporatenumerousperspectivesofanorganizationalculture.[190,191]

Conclusion

Failureofsoftwaremaybeduetoanyreasonbut themost importantoneis lackofriskmanagement or improper management of risks. Risk management is an increasinglyimportantbusinessdriverandstakeholdershavebecomemuchmoreconcernedaboutrisk.Risk may be a driver of strategic decisions, it may be a cause of uncertainty in theorganization or it may simply be embedded in the activities of the organization. An

enterprise-wide approach to risk management enables an organization to consider thepotentialimpactofalltypesofrisksonallprocesses,activities,stakeholders,productsandservices.Implementingacomprehensiveapproachwillresultinanorganizationbenefitingfromwhatisoftenreferredtoasthe‘upsideofrisk’.

ResearchinFutureFormalriskmanagementprocessmanagesmanycomplex issues thatareassociatedwithsoftwaredevelopmentprojectsandhavebeencreatedtoaidorganizationsbutatthetimeofintegrationofthoseprocessesintoorganizations,sometimes itwasnotsuccessfulandthusthetheoreticalaspectsoftheprocessmustbeconsistentwiththepracticalchallengesoftheorganizationtoimplementriskmanagementsuccessfully.Toacquireeffectiveriskmanagement process one has to change the organizational culture and motive theindividuals.

Riskmanagementinvolvesvarioustypesofproblemssoanorganizationshoulddoskillfulintegrationofsoftwaretechnology,economicsandhumanrelationsinabetterway.Asthesoftwareprojectinvolveshighlypeople-intensiveeffortandinvolvementofmanyclassesofpeoplesoariskmanagementprocessofafirmdependsonitssituation.

BIBLIOGRAPHYI.ResearchPapers[8]BrownN.,“Industrial-StrengthManagementStrategies”,IEEESoftware,Vol.13(4),1996,pp.94-103.

[9] Pearson N., “How Governance and Risk Management Enables Greater Innovation and Business Value fromInformationTechnologies”,November2007.

[11]BoehmB.,“SoftwareRiskManagement:PrinciplesandPractices”.IEEESoftware,Vol.8(1),1991,pp.32-41.

[12]CharetteR.,“SoftwareEngineeringRiskAnalysisandManagement”,McGrawHill,NewYork,NY,1989.

[13]JonesC.,PatternsofSoftwareSystemsFailureandSuccess.Boston,MA,InternationalThomsonComputerPress,1995.

[15]CarrM.J.etal.,“Taxonomy-BasedRiskIdentification”.SEITechnicalReportCMU/SEI-93-TR-006ESC-TR-93-183,SEI/CMU,Pittsburg,PA,1993.

[18]Ropponen J. andLyytinenK., “Components of SoftwareDevelopmentRisk:How toAddressThem?AProjectManagerSurvey”.IEEETransactionsonSoftwareEngineering,Vol.26(2),2000,pp.98-112.

[20]MiraKajko-MattssonandJaanaNyfjord,“StateofSoftwareRiskManagementPractice”,InternationalJournalOfComputerScience,20november2008.

[21]D.Wawrzyniak,M.Niedzwiedzinski,MarianNiedzwiedzinski,“ModelsofITriskassessment–classicalapproachandpossibilitiesofitsdevelopment“,2007.

[22]M.Ryba“MultidimensionalmethodologyofanalysisandmanagementofITsystemsrisk“Doctoral thesisAGH,Cracow,2006

[23]M.Ryba“AnalysisandmanagementofInformationSystemsrisk”,Ernst&Young2005.

[26]RonaldP.Higuera,YacovY.Haimes,“SoftwareRiskManagement”,CarnegieMellonUniversity,Pittsburgh,1996

[27]RayC.Williams,GoergeJ.Pandelios,SandraG.Behrens,“SoftwareRiskEvaluationMethodDescription”,version2.0,SoftwareEngineeringInstitute,CarnegieMellonUniversity,1999

[28] Anatoliy Antonov, Vladimir Nikolov, Yanka Yanakieva, “Risk Simulation in Project Management System”,InternationalConferenceonComputerSystemsandTechnologies-Compsystech,2006

[29] Daniel D. Galorath, Michael W. Evans, “Software Sizing Estimation and Risk Management”, AuerbachPublications,UnitedStatesofAmerica,2006,pp.339-393

[32]BarryW.Boehm, “SoftwareRiskManagement Principles and Practices”,DefenseAdvancedResearch ProjectsAgency,IEEESoftware,8(1):1991,PP.32-41

[35]AyadAliKeshlaf,KhairuddinHashim,“AModelandProtorypeTooltoManageSoftwareRisks”,FirstAsia-PasificConferanceIEEE,2000

[36]JyrkiKontio,“TheRiskitMethodforSoftwareRiskManagement”,version1.00,InstituteforAdvancedComputerStudiesandDepartmentofComputerScience,UniversityOfMaryland,1999

[41].Bohem,B.Softwareriskmanagement:principlesandpractices,IEESoftware,8,1(january1991).

[42].Bohem,B.andRoss,R.TheoryWsoftwareprojectmanagement:principlesandexamples, IEEETransactionsonsoftwareEngineering,15,7(july1989),902-916.

[46]..Bohem,B.SoftwareriskmanagementTutorial.WashingtonDC;IEEEComputerSocietyPress,1989.

[51].Karolak,D.W.softwareEngineeringRiskManagement.LosAlamitos,CA;IEEEComputerSocietyPress1996.

[55]BarryW.Boehm,UniversityofSouthernCaliforniaTomDeMarco,TheAtlanticSystemsGuild,“SoftwareRiskManagement”,1997,IEEE

[57][BentFlyvbjerg,NilsBruzelius,andWernerRothengatter,2003,MegaprojectsandRisk:AnAnatomyofAmbition(CambridgeUniversityPress).]

[58]OxfordBTCentreforMajorProgrammeManagement.

{59] Cortada, James W. (2003-12-04) The Digital Hand: How Computers Changed the Work of AmericanManufacturing,Transportation,andRetailIndustriesUSA:OxfordUniversityPresspp.512ISBN0195165888

[60]Cortada, JamesW. (2005-11-03)TheDigitalHand:VolumeII:HowComputersChanged theWorkofAmericanFinancial, Telecommunications, Media, and Entertainment Industries USA: Oxford University Press ISBN 978-0195165876

[61]Cortada,JamesW.(2007-11-06)TheDigitalHand,Vol3:HowComputersChangedtheWorkofAmericanPublicSectorIndustriesUSA:OxfordUniversityPresspp.496ISBN978-0195165869

[63]JohnAdams,RISK,Routledge1995

[64]DavidHillsonandRurhMurray-Webster,UnderstandingandManagingRiskAttitude,Gower2007

[65]DavidCooper,LeadershipRisk,Wiley2010

[71]GeoffTrickey(2011),RiskTypes.OPMattersNo14February2012TheBritishPsychologicalSociety

[72]YudistiraAsnar,PaoloGiorgini,“RiskAnalysisaspartoftheRequirementsEngineeringProcess”,DepartmentofInformationandCommunicationTechnology,2007

[73]BryanL.McKinney,DavidR.Engfer, “FormulatingRisk intoResearchandEngineeringProjects”,CrystalBallUserConference,2004

[74]AagedalJ.O.,denBraberF.,DimitrakosT.,GranB.A.,RaptisD.,StolenK.,“Model-basedRiskAssessmenttoImprove Enterprise Security”, 5th International Enterprise Distributed Object Computing Conference , Switzerland,IEEE,2002,PP.51-62

[75] Jyrki Kontio, “Software Engineering Risk Management: A Method, Improvement Framework and EmpiricalEvaluation”ISBN:952-5136-22-1,28thofSeptember,2001

[78]Boehm,B.W.,“Tutorial:SoftwareRiskManagement”,IEEEComputerSocietyPress,1989.

[80] Pandelios,G.,Rumsey, T. P.,&Dorofee,A. J., “UsingRiskManagement for Software Process Improvement”,SEPGConference,1996.

[81]Michaels,“TechnicalRiskManagement”,1996.

[84]Anon,Webster’sRevisedUnabridgedDictionary,1913

[87]Struik,D.J.,”AConciseHistoryofMathematics”,4edn,DoverPublications,NewYork.1987.

[88]Fisz,M.,“ProbabilityTheoryandMathematicalStatistics”,3edn,JohnWiley&Sons,NewYork.,1967.

[96] SEI 1993, Proceedings of the Second SEI Conference on Software Risk Management, Software Engineering

Institute,Pittsburgh,PA.

[97]SEI1994,ProceedingsoftheThirdSEIConferenceonSoftwareRiskManagement,SoftwareEngineeringInstitute,Pittsburgh.

[98] SEI 1995, Proceedings of the Fourth SEI Conference on Software Risk Management, Software EngineeringInstitute,Pittsburgh,PA.

[99]SEI1997,ProceedingsoftheFifthSEIConferenceonSoftwareRiskManagement,SoftwareEngineeringInstitute,Pittsburgh,PA.

[100]Pandelios,G.“SoftwareRiskEvaluationandTeamRiskManagement”,SEPGConferenceSoftwareEngineeringInstitute,1996

[101]Chittister,C.&Haimes,,“RiskAssociatedwithSoftwareDevelopment:AHolistic”,1993

[105]Fairley,“RiskManagementforSoftwareProjects”,IEEESoftware,vol.11,pp.57-67,May1994.

[106]Berny, J.&Townsend, “Macrosimulation of project risks— a practicalway forward”, International Journal ofProjectManagement,vol.11,no.4,pp.201-208,,1993

[107]Anon,“RiskAssessmentTechniques,”inDefenseSystemsManagementCollegeHandbook,pp.iv-1—25,F-1—13.1983

[108]Anon.1989,RiskManagement—ConceptsandGuidance,DefenseSystemManagementCollege,FortBelvoir,VA,U.S.A.,MDA903-87-C-0781.

[109]Anon,SoftwareRiskAbatement,DepartmentoftheAirforce,AdrewsAirForceBase,DC,800-45,1988

[114] Eslinger, S., Ellis, C. M., Hoting, S. K., & Walden, G. F. “PACE System Risk Analysis: An Application”,ConferenceonSoftwareRiskManagement,SEI,Pittsburgh,PA.

[115]Meyers,D. J.&Trbovich,D.R.“OneProject’sApproach toSoftwareRiskManagement”, SEIConferenceonSoftwareRiskManagement,Pittsburgh,PA.

[116]Morin,J.-M.“RiskDrivenProjectManagement:APracticalApproach”,SecondSEIConferenceonSoftwareRiskManagement.

[118]BoehmB.W.,“SoftwareEngineeringEconomics”,1981

[120]Rescher,“Risk:APhilosophicalIntroductiontotheTheoryofRiskEvaluationandManagement”,1983.

[121]Sisti,F.J.&Joseph,,”SoftwareRiskEvaluationMethod”,Version1.0,CMU/SEI-94-TR-19.1994.

[122]Alter,S. andGinzberg,M. (1978) “Managinguncertainty inMIS implementation,”SloanManagementReview,20(1),23-31.

[123]Zmud,R.W.(1980)“Managementoflargesoftwaredevelopmentefforts,”MISQuarterly,4(1),45-55.

[124]Barki,H., Riverd, S., and Talbot, J. (1993) “Toward an assessment of software development risk,” Journal ofManagementInformationSystems,10(2),203-225.

[125]Boehm,B.W.(1991)“Softwareriskmanagement:principlesandpractices.”IEEESoftware,8(1),32-41.

[126]Bennett,J.C.,Bohoris,G.A.,Aspinwall,E.M.,&Hall,R.C.(1996)“Riskanalysistechniquesandtheirapplicationtosoftwaredevelopment,”EuropeanJournalofOperationalResearch,95(3),467-475.

[127] Newman, M. (1996) “Determinants of commitment to information systems development: a longitudinalinvestigation,”MISQuarterly,20(1),23-54.

[128]Boehm,B.W.,DeMarco,T.,1997.Softwareriskmanagement.IEEESoftware14(3),17–19.

[129]Klein,S.A.,1998.Puttingmethodologyinperspectivefromaprojectriskviewpoint.In:IEEEPowerEngineeringSociety1999WinterMeeting,vol.1,,pp.362–365.

[130]vanGenuchten,M.,1991.Whyissoftwarelate?Anempiricalstudyofreasonsfordelayinsoftwaredevelopment.IEEETransactionsonSoftwareEngineering17(6),582–590.

[131]MarvinJ.Carr,SureshL.Konda,IraMonarch,F.CarolUlrich,Clay

F.Walker,“Taxonomy-BasedRiskIdentification”,CarnegieMellon

university,PittsburghPennsylvania,1993

[132]RobertArmstrong,GillianAdens,“ManagementSoftwareProjectRisk”,

2004

[133]HuYong,ChenJuhua,RongZhenbang,MeiLiu,Xie

[134]JohnD.McGregor,DavidA.Sykes,“APracticalGuidetoTestingObject-OrientedSoftware”,Addison-Wesley,2001,pp.87-92

[135]HoomanHoodat,andHassanRashidi“ClassificationandAnalysisofRisksinSoftwareEngineering”2009

[136]Glutch,D.P.1994.AConstructforDescribingSoftwareRisks,TechnicalReport,Report#CMU/SEI-94-TR-14,SoftwareEngineeringInstitute,CarnegieMellonUniversity,Pittsburgh,PA,USA.

[137]Kontio, J. 2001.SoftwareEngineeringRiskManagement:AMethod, ImprovementFramework, andEmpiricalEvaluation. Ph.D. Thesis, Department of Computer Science and Engineering, Hensinki University of Technology,Finland,2001.

[138]Bernoulli,D.1954.“ExpositionofNewTheoryontheMeasurementofRisk”,Econometrica,22:23-36.

[139]Hogarth,R.M.1987.JudgmentandChoice,JohnWiley&Sons,NewYork,USA.

[140]Simon,H.A.1979.RationalDecisionMaking inBusinessOrganizations.TheAmericanEconomicReview,69(4),493-513.

[141]KahnemanD.,andTverskyA.1973.“OnthePsychologyofPrediction”,PsychologyReview,80,237-251.

[142]Kahneman,D.,Slovic,P.,andTversky,A.1982.JudgmentunderUncertainty:HeuristicsandBiases,CambridgeUniversityPress,NewYork.

[143]Boehm,B.W.1988.“ASpiralModelofSoftwareDevelopmentandEnhancement”,Computer,May,61-72.

[144]Boehm, B. W. and Bose, P. 1994. “A Collaborative Spiral Software Process Model Based on Theory W”,Proceedingsofthe1994InternationalConferenceonSoftwareProcess,IEEEComputerSociety,Washington.

[145]Boehm,B.W.andRoss,R.1988.“Theory-WSoftwareProjectManagement:ACaseStudy”,Proceedingsof the1988InternationalConferenceonSoftwareEngineering,Singapore,30-40.

[146]Boehm,B.W.1988.“ASpiralModelofSoftwareDevelopmentandEnhancement”,Computer,May,61-72.

[147]Boehm,B.W.etal.1988.“UsingtheWin-WinSpiralModel:ACaseStudy”,IEEEComputer,31(7),33-44.

[148]Williams,R.C,etal.1999.SoftwareRiskEvaluation(SRE)MethodDescription(Version2.0),TechnicalReport,Report#CMU/SEI-99-TR-029,SoftwareEngineeringInstitute,CarnegieMellonUniversity,Pittsburgh,PA,USA.

[149]Hall,E.M.1998.ManagingRisk:MethodsforSoftwareSystemsDevelopment,Addison-Wesley,Reading,U.K.

[150]Adams, J. (1999)“Cars,cholera, andcows, themanagementof riskanduncertainty.”PolicyAnalysis,No.335.Washington,DC:CatoInstitute[152] Subhas C. Misra,Vinod Kumar “DIFFERENT TECHNIQUES FOR RISKMANAGEMENT IN SOFTWAREENGINEERING:AREVIEW”2006

[153]Keshlaf,A.A.,Hashim,K.,2000.Amodelandprototypetooltomanagesoftwarerisks.In:ProceedingsofFirstAsia–PacificConferenceonQualitySoftware,,pp.297–305.

[154]Abdullah S.Al-Mudimigh,Basit Shahzad,ZahidUllah,“Identification ofMethodology for Analysis of the RiskFactors inSoftwareDevelopmentEnvironment”,Global JournalofComputerScienceandTechnology,Vol.10 Issue1(Ver1.0),April2010

[155]KamranKhan,Zaeemahmad,BasitShahzad,―Adressingproblemsandrisksinsoftwaredevelopmentlifecycleǁ,7thCIITWorkshoponResearchinComputing,heldatLahoreJune23,2008,pp123-128.

[156]BasitShahzad,SaraSafvi,―Riskmitigationandmanagementschemebasedonrisk‘spriorityǁ,acceptedin7thWSEASconferenceheldinHangzhou-China,April6-8,2008.pp86-91

[157] Basit Shahzad, Javed Iqbal, ―ǁSoftware Risk Management – Prioritization of frequently occurring Risk inSoftwareDevelopmentPhases.UsingRelativeImpactRiskModelǁ,2ndInternationalConferenceon InformationandCommunicationTechnology(ICICT2007),December16-17,2007,IBAKarchi.

[158] Javed Iqbal, Basit Shahzad, ―Prioritization and Handling of Commonly Occurring Risks– An AnalyticalApproachǁ,5thconferenceonIntelligentSystems&Networks,February22-24,2008(ISN-2008),Haryana,India

[159]BasitShahzad,JavedIqbal,ZeeshanulHaq,SaleemRazaandSalmanAslam―Distributedriskanalysisusingrelativeimpacttechniqueǁ,3rdAsianConferenceonIntelligentSystemsandNetworks,February24-25,2006,Haryana-India,pp433-439.

[160] Basit Shahzad, Najam us saqib,―Escape from delays and failures for software solutionsǁ, 6th JordanianInternationalElectronicandElectricalEngineeringConferenceinAmman-Jordan,March14-16,2006.

[161]BasitShahzad,TanvirAfzal,―Enhancedriskanalysisandrelativeimpactfactorizationǁ,1stIEEEinternationalconferenceoninformationandcommunicationtechnology,IBAKarachi,August27-28,2005,pp290-295.

[162]Moynihan,T.Howexperiencedprojectmanagersassessrisk.IEEsoftware,14,3(May/June1997)35-41.

[163]Ropponen, J.,Lyytinen,K.,1997.Cansoftware riskmanagement improvesystemdevelopment:anexploratorystudy.EuropeanJournalofInformationSystems6(1),41–50.

[164]IEEEsoftwareengineeringstandardscollection,IEEE-STD-610.12,1990.

[165]Boehm,B.W.,1991.Softwareriskmanagement:principlesandpractices.IEEESoftware8(1),32–41.

[166]Barki,H:RivardS;andTalbot,J.Towardanassessmentofsoftwaredevelopmentrisk.JournalofmanagementinformationSystems,10,2(Fall1993)203-225.

[167]HeemstraF. andKustera,R.Dealingwith risk; a practical approach, Journal of informationTechnology, 11, 4(December1996),333-446.

[169]BarryW.Boehm,TomDeMarco,”guesteditors’introduction”,IEEESoftware,May/June1997

[170] James Bach,“Heuristic Risk-Based Testing”First published in Software Testing and Quality EngineeringMagazine,11/99,1999

[171] EDMUND H. CONROW,PATRICIA S. SHISHIDO,“Implementing Risk Management on Software IntensiveProjects”,IEEESOFTWARE,1999

[173]AvižienisA., Laprie J.-C., Randell B., Landwehr C., Basic Conceptsand Taxonomy ofDependable and SecureComputing,IEEETransactionsonDependableandSecureComputing,vol.1,no.1,2004

[174]Proceedingsofthe1994InternationalConferenceonSoftwareProcess,IEEEComputerSociety,Washington.

[175]Boehm,B.W.andRoss,R.1988.“Theory-WSoftwareProjectManagement:ACaseStudy”,Proceedingsof the1988InternationalConferenceonSoftwareEngineering,Singapore,30-40.

[176]Boehm, B.W.andRoss,R. 1989. “Theory W Software Project Management: Principles and Examples”. IEEETransactionsonSoftwareEngineering.15(7):902-916.

[178] Implementing Risk Management on Software Intensive Projects EDMUND H. CONROW, IndependentConsultantPATRICIAS.SHISHIDO,TRWSystemsIntegrationGroup

[179] AMethod of Software Project Risk Identification and Analysis JakubMiler Supervised[180] Beynon, D., C.Carne,H.MackayandD.Tudhope(1999)“RapidApplicationDevelopment:Anempiricalreview”,EuropeanJournalofInformationSystems,(1999).

[181]Boehm,B.W.(1989)“Riskmanagementfocuses theprojectmanager’sattentionon thoseportionsof theprojectmost likely to cause trouble and compromise participants’winconditions.” IEEEComputer Society Press,NewYork,1989”.

[182]Charette,R.N.(1989)“SoftwareEngineeringRiskAnalysisandManagement,McGraw-HillNewYork,1989”.

[183]GaryM.(2004)“RiskAnalysisinSoftwareDesign”,IEEEComputerSociety,2004.

[184]Issam,J.Z.(2003)“TheRapidApplicationDevelopmentProcess”,Quantume-SolutionsInc.3920MysticValleyPkwy1118,MedfordMA02155,2003.

[185]KarlG.(2002)“SoftwareDevelopmentRiskManagement”,CSCI510Report,2002.

[186]Chung, L, Nixon, B.A.,Yu, E. and Mylopoulos J. 2000. Non-Functional Requirements in SoftwareEngineering.KluwerAcademicPublishers.

[187]Deursen, A. v. and Kuipers, T. 2003.Source-Based Software Risk Assessment.Proceedings of the 2003InternationalConferenceonSoftwareMaintenance,Amsterdam,Netherlands.

[188]Donzelli, P. 2002. “Agents,Goals, andQuality in a StructuredRequirementsEngineeringFramework -ACaseStudy”.Proceedingsof2002CAiSE‘02,Toronto,Ontario.

[190]Dorofee, A. J. et al. 1996. Continuous Risk Management Guide Book, SEI, Carnegie Mellon University,Pittsburgh,PA,USA.

[191]Projectriskmanagement: lessons learnedfromsoftwaredevelopmentenvironmentY.H.Kwaka,,J.StoddardbaProjectManagementProgram,DepartmentofManagementScience,MonroeHall403,SchoolofBusinessandPublicManagement, TheGeorge Washington University, Washington, DC 20052, USA b Agilent Technologies, 2679MonumentDrive,SantaRosa,CA95407,USA

[192]Higuera, P. Ronald &Haimes, Y. Yacov, 1996. Software Risk Management, June.Available at:http://www.sei.cmu.edu/pub/documents/96.reports/pdf/tr012.96.pdf,Pittsburgh,

[193]IBM, 2008. Winning in Midmarket:100 Software Success Stories June. Availableat:ftp://ftp.software.ibm.com/software/smb/casestudies/expresscasestudy.pdf

[194]AhernD.,ClouseA.,TurnerR.,CMMIDistilled.2ndEd.Addison-Wesley,Boston,MA,2005.

[195]BoehmB.,“SoftwareRiskManagement:PrinciplesandPractices”.IEEESoftware,Vol.8(1),1991,pp.32-41.

[196]BrownN.,“Industrial-StrengthManagementStrategies”,IEEESoftware,Vol.13(4),1996,pp.94-103.

[197]CarrM.J.etal.,“Taxonomy-BasedRiskIdentification”.SEITechnicalReportCMU/SEI-93-TR-006ESC-TR-93-183,SEI/CMU,Pittsburg,PA,1993.

[198]CharetteR.,“SoftwareEngineeringRiskAnalysisandManagement”,McGrawHill,NewYork,NY,1989.

[199]DeMarcoT.,“RiskManagementforSoftwareProjects”.TheAtlanticSystemsGuild,Camden,ME,2004.

[200] Eclipse Process Framework (EPF), OpenUP Process. URL: http://www.eclipse.org/epf/. Accessed November2007.

[201]Fairley,R.,“RiskManagementforSoftwareProjects”.IEEESoftware,Vol.11(3),1994,pp.57–67.

[202] Hulett D.T., “Key Characteristics of a Mature Risk Management Process”. Proc. of the European ProjectManagementConf./PMIEurope,2001.

[203]IEEE1540,IEEE1540StandardforLifecycleProcesses-RiskManagement.IEEE,NewYork,NY,2001.

[204]IEEESoftware,“ManagingRisk”(specialissue).IEEESoftware,Vol.14(3),1997.

[205] Institute of Risk Management, Association of Insurance and Risk Managers, National Forum for RiskManagementinthePublicSector,ARiskManagementStandard.IRM,UK,2002.

[206]InternationalStandardisationOrganzation(ISO),ISO9001:2000forQualitymanagement.ISO,Switzerland,2000.

[207] Na K. et al., “Software Development Risk and Project Performance Measurement: Evidence in Korea.” TheJournalofSystemsandSoftware,Vol.80,2007,pp.596-605.

[208]NyfjordJ.andKajko-MattssonM.,“CommonalitiesinRiskManagementandAgileProcessModels”.Proc.of2ndInt.Conf.onSoftwareEngineeringAdvances,France,2007.

[209]NyfjordJ.andKajko-MattssonM.,“CommunicatingRiskInformation inAgileandTraditionalEnvironments”.Procedingsof33rdEuromicroConferenceonSoftwareEngineeringandAdvancedApplications,2007.

[210]Nyfjord andKajko-Mattsson, “Degree ofAgility in Pre-Implementation Process Phases”.Accepted at the 19thAustralianSoftwareEngineeringConference,Australia,March2008.

[211]Nyfjord J. andKajko-MattssonM., “SoftwareRiskManagement:PracticeContraStandardModels”.TechnicalReport,DepartmentofComputerandSystemsSciences,StockholmUniversity/KTH,Sweden,2008.

[212] Project Management Institute, AGuide to the Project Management Body of Knowledge (PMBoK), 3rd Ed.ANSI/PMI99-001-2004,PMI,NewtonSquare,PA,2004.

[213]RobsonC.,RealWorldResearch.BlackwellPublishing,2002.

[214]RopponenJ.andLyytinenK.,“ComponentsofSoftwareDevelopmentRisk:HowtoAddressThem?AProjectManagerSurvey”.IEEETransactionsonSoftwareEngineering,Vol.(2),2000,pp.98-112.

[215]StandardsAustraliaandNewZealand,Australian/NewZealandStandardRiskManagementAS/NZS4360:2004.3rdEd.,StandardsAustralia/NewZealand,2004.

[216]StandardsAustraliaandNewZealand,Australian/NewZealandStandardRiskManagementAS/NZS4360:2004.3rdEd.,StdsAustralia/NewZealand,2004.

[217] Zdravkovic J., Process Integration for the Extended Enterprise, Doctoral Thesis in Computer and SystemsSciences.RoyalInstituteofTechnology,Sweden,2007.

II.PDFfiles[2]Y.H.Kwaka,*,J.Stoddardb,”Projectriskmanagement:lessonslearnedfromsoftwaredevelopmentenvironment”pageno-915–920,2004,

[3]Basit Shahzad, ZahidUllah,Abdullah S.Al-Mudimigh, “Identification ofMethodology forAnalysis of theRiskFactors in SoftwareDevelopment Environment”Vol. 10 Issue 1 (Ver 1.0) published inGlobal Journal of ComputerScienceandTechnology,April2010.

[5]DR.E.WALLMÜLLER,”RiskManagementforITandSoftwareProjects”.

[6]KennethK.Humphreys“PROJECTRISKMANAGEMENT-ADVANTAGESANDPITFALLS”.

[7]HoomanHoodat,andHassanRashidi,“ClassificationandAnalysisofRisksinSoftwareEngineering”,publishedinWorldAcademyofScience,EngineeringandTechnology56,2009

[14]NaK.etal.,“SoftwareDevelopmentRiskandProjectPerformanceMeasurement:EvidenceinKorea.”TheJournalofSystemsand

[17]Nidumolu,S.,“TheEffectofCoordinationandUncertaintyonSoftwareProjectPerformance:ResidualRiskasanInternational

[19]WallaceL.andKeilM.,“SoftwareProjectRisksandTheirEffectonOutcomes.CommunicationsoftheACMVol.47(4),2004,pp.68-73.

[24]KennethK.Humphreys,“PROJECTRISKMANAGEMENT-ADVANTAGESANDPITFALLS”.

[25] Rita C. Nienaber, Andries Barnard, “A Generic AgentFramework to Support the Various Software ProjectManagementProcesses”,InterdisciplinaryJournalofInformation,Knowledge,andManagement,Vol.2,2007

[34]MarciodeOliveiraBarros,ClaudiaMariaLimaWerner,GuilhermeHortaTravassos,”SupportingRisksinSoftwareProjectManagement”,TheJournalofSystemsandSoftware,PublishedbyElsevierInc,2002

[37].Gibbs,W.W.softwraer’schroniccrisis.ScientificAmerican,271.3(september1994),86-95.

[38]. Lyytinen, K.L. , and Hirscceim, R. Information systems failures- a survey and classification of the empiricalliterature. InP.I.Zorkoozy (ed.)OxfordSurveys in informationTechnology,Vol $, oxford:OxfordUniversityPress,1987,pp.257-309.

[39]. vanGenuchten,M.why is software late?An emprirical study of the reason for delay in softwrae development,IEEETransactionsonsoftwareEngineering,17,6(June1991),582-590

[40].Walkerden, F. and Jeffery, Software cost estimation: a review ofmodels, processes, and practice.Advances incomputers,Vol.44SanDiego:AcademicPress,1997,pp.62-94.

[44].Alter,S.andGinzberg,M.ManaginguncertainityinMISimplementation.SloanManagementReview20,1(Fall1978),23-32.

[45].Barki,H:RivardS;andTalbot, J.Towardanassessmentof softwaredevelopment risk. JournalofmanagementinformationSystems,10,2(Fall1993)203-225.

[47].Heemstra F. andKustera,R.Dealingwith risk; a practical approach, Journal of informationTechnology, 11, 4(December1996),333-446.

[48].McFarianF.W.Portfolioapproachtoinformationsystems.HarvardBussinessReview,59,5(september/October1981),142-150.

[49].Moynihan,T.Howexperiencedprojectmanagersassessrisk.IEEsoftware,14,3(May/June1997)35-

[50]. Offenbeek, M. Koopman. P. Scenarios for system development: matching context and stragies. Behaviour &Information,15,4(1996)250-165.

[52].Johnson,J.Chaos:thedollardrainofITprojectfailures.ApplicationDevelopmentTrends,2,1(January1995),41-47.

[53] Don Gotterbarn, Simon Rogerson, “RESPONSIBLE RISK ANALYSIS FOR SOFTWARE DEVELOPMENT:CREATINGTHE SOFTWAREDEVELOPMENT IMPACT STATEMENT”, Communications of theAssociation forInformationSystems(Volume15,2005)pp:730-750

[54]KennethA.Froot,DavidS.Scharfstein,JeremyC.Stein,“RiskManagement:CoordinatingCorporateInvestmentandFinancingPolicies”,TheJournalofFinance,Vol.48,No.5.(Dec.,1993),pp.1629-1658.

[66]Digman,J.M.(1990)PersonalityStructure:TheemergenceoftheFive-FactorModel.InM.R.RosenzweigandL.W.Perter(Eds.),Annualreviewofpsychology(Vol.41,pp.417-440).PaloAlto,Calif.:AnnualReviews.

[68]Nicholson,N.,Soane,E.,Fenton-O’Creevy,M.,&Willman,P.,(2005)Personalityanddomainspecificrisktaking.JournalofRiskResearch,8,157-176.

[69]McCrae,R.,&Costa,P.T.(1997)ConceptionsandcorrelatesofOpennesstoExperience.InJ.Johnson,RHoganandS.Briggs(Eds.)HandbookofPersonalityPsychology.London:AcademicPress.

[70]Kowert,P.A.,&Hermann,M.G.(1997).Whotakesrisks?Daringandcautioninforeignpolicymaking.JournalodConflictResolution,411,611-37.

[82]Covello,V.T.&Mumpower,J.1998,“RiskAnalysisandRiskManagement:AhistoricalPerspective,”,PlenumPress,NewYork,pp.519-540.

[83]David,E.S.Pearson,M.Kendall,“DicingandGaming(anoteonthehistoryofprobability)”,CharlesGriffin&CompanyLtd,London,pp.1-15.,1978.

[85]Sambursky,S.1956,“OnthePossibleandProbablyinAncientGreece”,Osiris,vol.12,pp.35-48.

[89]Nolan,“ManagingtheComputerResource:AStageHypothesis”,CommunicationsoftheACM,vol.16,no.7,pp.399-405,1973

[90]Nolan,“ManagingtheCrisesindataprocessing”,pp.115-126.1979.

[91]McFarlan,,“Portfolioapproachtoinformationsystems”,pp.142-150,1974.

[95]Boehm,B.W.,“ASpiralModelofSoftwareDevelopmentandEnhancement”,IEEEComputer,vol.21,no.5,pp.61-72,1988

[102]Carr,M.J.,Konda,S.L.,Monarch,I.A.,Ulrich,F.C.,&Walker,C.F.,“Taxonomy-BasedRiskIdentification”,SEITechnicalReportSEI-93-TR-006,1993.

[103]Laitinen,L.,Kalliomäki,S.,&Känsälä, ,“OhjelmistoprojektienRiskitekijät,Tutkimusselostus” N:oL-4,VTT,,1993.

[110]Edgar,J.D.1989,“ControllingMurphy:HowtoBudgetforProgramRisk”,pp:.60-73,1982.

[112]Boehm,B.W. “SoftwareRiskManagement:Principles andPractices”, IEEESoftware, vol. 8, no. 1, pp. 32-41,1991.

[113]Chittister,C.,Kirkpatrick,R.J.,&VanScoy,“RiskManagementinPractice”,AmericanProgrammer,vol.5,no.September,pp.30-35,1992

[117]Conrow,E.H.&Shishido,“ImplementingRiskManagementonSoftwareIntensiveProjects”,IEEESoftware,vol.14,no.3,pp.83-89,1997.

[119]BoehmB.W.,“IndustrialSoftwareMetricsTop10List”,IEEESoftware,vol.4,no.September,pp.84-85.,1987

[151] Gary Stoneburner, Alice Goguen, and Alexis Feringa “Risk Management Guide for Information TechnologySystems”

III.BooksReferred[30]PhilippeKruchten,“TheRationalUnifiedProcessanIntroduction”,Thirdedition,AddisonWesley,2003,chapter7

[31]C.RavindranathPandian,“AppliedSoftwareRiskManagementaGuideforSoftwareProjectManagers”,AuerbachPublications,UnitedStatesofAmerica,2007,Chapters2,3,5

[33]RogerS.Pressman,Ph.D.,“SoftwareEngineeringaPractitionersApproach”,5thEdition,McGraw-Hill,2001,pp.145-159

[43].Charette,R.SoftwareEngineeringRiskAnalysisandManagement.NewYork:McGrawHill,1989.

[67]EysenckM.W.(1992)AnxietyandTheCognitivePerspective.Hillsdale:LawrenceErlbaumAssociates

[76]Crouhy,M.,Galai,D.,&Mark,“RiskManagement”,McGraw-Hill.,2001.

[77] Dorofee, A. J., Walker, J. A., Alberts, C. J., Higuera, R. P., Murray, T. J., & Williams, “ Continuous RiskManagementGuidebook”,1996.

[79]Charette,”SoftwareEngineeringRiskAnalysisandManagement”,McGraw-Hill,NewYork.1989.

[86]Bernstein,P.L.1996,AgainsttheGods,JohnWiley&Sons,NewYork.

[93]Davis,“StrategiesforInformationRequirementsDetermination”,IBMSystemsJournal,vol.21,no.1.1982

[94]Saarinen,“SuccessofInformationSystems”,1993.

IV.OtherSources[1]http://informationr.net/ir/7-3/paper129.html.

[4]http://www.thedacs.com

[62]http://www.bowtiexp.com.au/bowtiexp.asp#aboutBowTies

[168]http://www.project-management-basics.com/risk-management-4.shtmlriskmanagementapproach

[172]http://www.sei.cmu.edu/news/

[177]www.accenture.com/GlobalRiskManagementResearch2011www.accenture.com/GlobalRiskManagementDiagnostic2011

AboutAuthor(s)

112

RetardationinSoftwareFailureRate

MayankJindal

Mr.MayankJindalisanAssistantSystemEngineerinTataConsultancyServicesLtd.Hedid B.Tech in Information Technology from Rajasthan Technical University, Jaipur,Rajsthan,India

Hehaspresented7researchpapersinvariousInternationalandNationalConferences.Hisresearch interests include Computer Networks, Operating System and DatabaseManagementSystem.

NehaGupta

Ms.NehaGuptaisanAssistantProfessorintheDepartmentofInformationTechnologyofJaipur Engineering College & Research centre, Jaipur. She Did B.Tech in InformationTechnologyfromuniversityofRajsthan.Jaipur,Rajsthan, IndiaandM.Tech inSoftwareEngineeringfromGyanViharUniversity.Jaipur,Rajsthan,India.

She has 6 years and 6 months of teaching experience. She has presented 10 research

papers invarious International andNationalConferences.Her research interests includeSoftwareEngineering,DatabaseManagementSystem.

SunilKumarJangir

Mr.Sunil Kumar Jangir is an Assistant Professor in the Department of InformationTechnologyofJaipurEngineeringCollege&Researchcentre,Jaipur,Rajsthan,India.

HedidB.TechinInformationTechnologyfromUniversityofRajasthan,Jaipur,Rajsthan,IndiaandM.techinSoftwareEngineeringfromGyanviharUniversity,Jaipur,Rajsthan,India. He has 3 years and 6 Months of teaching and industrial experience. He haspresented 15 research papers in various International and National Conferences. Hisresearch interests include Software Engineering, Knowledge Management, Informationsecurity,SoftwareProjectManagement.

112

RetardationinSoftwareFailureRate

112