JOURNAL OF COMPUTER SCIENCE AND ENGINEERING, VOLUME 13, ISSUE 1, MAY 2012 21

Enhanced IT Project Risk Management Process Framework

Pradnya Purandare
AbstractLast 20 years although the numbers of IT projects are increasing, the failures have not been reduced as much as required. It is necessary that the software projects incorporate the Risk management practices in its life cycle. The Risk Management process is an essential part of the project management process. These standards are systematic and help identifying, analyzing and reducing the projects risks. The PMI PMBOK and ISO [2] both project risk management standards were studied. The researcher found that there is a scope for improvement within the framework suggested by PMI PMBOK and ISO [2] for the Risk management process framework. Their limitations and strengths were enablers for the proposed solution. Researcher proposed enhanced framework for IT Project Risk Management, based on the best practices, processes proposed by PMI PMBOK and ISO [2]. Index TermsIT Risk Project Management Process Standards, IT Risk Project Management Process enhancement, Strengths & limitations of IT Risk Project Management Process Standards

1 INTRODUCTION

Every day there is growth in the Software projects offering services, products to various business domains. But software projects are prone to failure. Studies on IT projects reveal that American companies spent $59 billion in 1995 on cost overruns. Several of such examples from 1990 onwards suggest that even though the project managers might have avoided risks but the organizations might have failed to learn from previous experiences [1]. As per the study conducted on IT project risk assessment in 2007, Software project failure is 23%, frequency of challenged projects 49%, while identifying more than fifty major risk factors driving the project towards failures [2]. Standish Report December, 2010 analyzed IT projects in the area of applications modernization, package applications, application development indicates that 39% to 54% projects are challenged projects and 8% to 49% projects are failed [3]. This indicates that from 1990 till 2010 i.e. in 20 years although the numbers of IT projects are increasing, the failures have not been reduced as much as required. An understanding of the software project failure indicates that the major factors are unmanaged uncertainties in the projects. There are Risks evolving due to uncertainties. The software projects use Risk Management as a process to reduce the risks, to improve the chances of project success [4]. The study found project dimensions are dependent on the high order of overall project risk, indicating that risk is inversely proportional to project success [4]. The risks can be categorized as impacting respectively to the project success. Hence it is necessary that the software projects

oftware projects are capturing many facets of life.

incorporate the Risk management practices in its life cycle.

2 RESEARCH PROBLEM 2.1 Review Stage? Existing Software Project management practices and frameworks standards were implemented by compliances. These standards are systematic and helps identifying, analyzing and reducing the projects risks. The Risk Management process is an essential part of the project management process. The Risk Management processes and practices framework provided by PMI PMBOK was studied. The Risk Management processes and practices framework provided by ISO [2] was also studied. It was found that both help the projects in reducing the impacts of negative risks on project success. It was found both of the above methodologies are strong enough to be applied to the projects individually; the researcher found that there may be a scope for improvement within the framework suggested by PMI PMBOK and ISO [2] for the Risk management process framework [5-7]. 2.2 Proof that problem exists and pain areas
Project uncertainties at complex level are difficult to quantify, this requires management tolerance and flexibility perspective into the risk management practices and framework. There is explicit need to train all stakeholders about the highest level of uncertainty which can become organization culture during the risk identification process. One of the pain areas of managing uncertainty is enough attention to project life cycle phases, its completion and strategic aspects of projects are not considered [8].

Pradnya Purandare is with Symbiosis Centre for Information Technology, Pune, MAH India.

2012 JCSE www.journalcse.co.uk

22

A Delhi study has found that there is a difference between the userss and project managers project risk management perspectives with respect to the risk factors. Hence if the risk management process framework does not give correct emphasis on users and project teams concordance and discordance with the views of risk factors, in the later stages of the project, user acceptance may become difficult to be achieved [9]. Such situations arise when the project planning is the joint responsibility of the user and the vendor, specifically for internal IT projects. PMI recognized the uncertainty monetary value, based on task value and occurrence probability and its impact on the project [10]. With respect to the severity and detection of risk, PMBOK PMI approach expects risk severity to be expressed in monetary value, which depends on the calculated value and occurrence probability of those risk related task. 1) 2) 3) Assign a probability of occurrence of the risk. Assign monetary value of the impact of the risk when it occurs. Multiply Step 1 and Step 2.

project risk occurs, the project gains $10,000, and HR Turmoil negative project risk occurs the project loses $ 7,500. The projects Expected Monetary Value based on these project risks are: - ($20,000) + ($10,000) ($7,500) = - $17,500 Therefore, if all the above mentioned risks occur in the IT project, the project would lose $17,500. In this scenario, the project manager can add $17,500 to the budget to compensate for this. Complex Expected Monetary Value calculations can be done conducting Decision Tree Analysis. This analysis helps while making decisions for projects with complex project risks. Another way of a project risk analysis is severity analysis having different stakeholder perceptions of risks. If important stakeholders opinion is not incorporated, then the probability and impact calculated can be away from the reality. Thus in the severity analysis different stakeholders visions would be involved [10]. PMI PMBOK identifies Time Dimension as the critical factor in Risk identification and risk response adoption. But there is a possibility of errors if the risks have been responded at wrong time. Also, if these errors are identified early in the project lifecycle it will have less negative impact on the project success [10]. The project risk management focuses mainly on improving time and budget goals. It is having less focus on the product performance and product specification [11]. The study conducted on Software development project risk management, has shared some lessons learned which express the need to incorporate the key functional risk management behavior in the organization by the senior management. It suggests that during critical situations in the project, the focus is mainly at the short-term goals to be achieved and to neglect long term risks. These can show overruns of cost and schedule. This can lead the attitude to be reactive towards the risks than proactive approach in risk management [12]. The organizations which practice the implementation of effective business processes are more successful in managing risks than the ones which have ineffective business processes. Theoretical aspects of the process must be reconciled with the practical challenges of the organization in implementing the risk management successfully [12]. Generally the non-listed first three or five risk events may not be important at that moment and hence they are neglected, but later they may become of high priority in the life cycle and still neglected. During such a case, a feedback loop can be helpful in checking the status of the current highest risk events, and continually reduce it [13]. Many software tools are available for various Risk management Processes like MS Project which consists of Project Risk Management, @Risk, RiskComplete, Risk register, Risk Matrix and many more. An empirical study revealed the significantly higher usage of software tools is done in the risk management processes: Risk Impact Assessment, Risk Classification and

EMV the Risk = Probability of occurrence of the risk x monetary value of impact of the risk EMV is positive for opportunities i.e. positive risks and negative for threats i.e. negative risks as the need to identify these both type of risks in the project risk management. E.g. Expected Monetary Value calculation for Project Risk Management In this Expected Monetary Value example, we have two negative project risks (Effect of global economy on project and HR Turmoil) and a positive project risks (Cost of IT Solution development). The Expected Monetary Value for the project risks: Effect of global economy on project: 25/100 x (-$80,000) = - $ 20,000 Cost of IT Solution development: 10/100 x ($100,000) = $ 10,000 HR Turmoil: 5/100 x (-$150,000) = - $7,500 Though the highest impact is caused by the HR Turmoil project risk, the Expected Monetary Value is the lowest. This is because the probability of it occurring is very low. Thus, Effect of global economy negative project risk occurs, the project loses $20,000, of IT Solution development positive

23

Ranking of Risks, Periodic document reviews, Periodic trend reporting, Analysis of trends, deviations and exceptions, subcontractor management, quality management, training programs, customer satisfaction surveys [14].

2.

3. Findings
The study of Risk Management Process framework by ISO [2] and PMI PMBOK enabled the researcher, to find the following limitations and advantages of these Risk Management process frameworks: 3.1 Limitation in Risk Management Process framework by ISO [2]. (Found to be Strengths of PMI PMBOK Risk management planning) 1. It does not include the Project Risk Management Planning in the beginning of the Risk Management Process. Due to this the scope plan, schedule plan, cost plan, communication plan, organizational process assets, enterprise environmental factors are not included in the planning of the risk management process. And hence it is not able to percolate further as the Risk Management Plan to the Risk identification process. This first step of Risk management planning is very crucial as the inputs from each of the individual detailed scope plan, schedule plan, cost plan, communication plan if not included in risk identification may not be done in depth, and there is a possibility of assumptions about all the above plans since they have each process, task, activity detailed. The important aspect about the risk planning is to happen at the macro level of Risk Management Planning phase at the beginning. 2. Qualitative and Quantitative Analysis is not separated individually, and single Risk Analysis has been addressed. 3. The enhanced Risk Management framework process model developed by the researcher has retained most of the processes identified by PMI PMBOK Risk management as the input, process tools and output. The PMI PMBOK has in depth explicitly mentioned the important project management plans to be reviewed prior identifying the risks. It distributes the qualitative and quantities risk analysis giving a subjective and objectivity to the analysis process, and to move towards the accuracy in analysis. It has offered very good techniques like probability and impact matrix, Delphi techniques etc. 3.2 Advantages of Risk Management Process framework by ISO [2] (Found to be Limitations of PMI PMBOK Risk management planning) 1. In the Risk Identification process, it incorporates the inputs from the product description, constraints, and assumptions. It facilitates the overall risks to be viewed from business and functional, non-functional requirements perspectives. This will enable a top view of the major risks for the entire project. Overall constraints are necessary to be 3.

known at this stage, as they are the important ingredients of the inputs in deciding if the identified risk can be mitigated, and if it is to be mitigated, what are the constraints for this project, what is the severity of the constraints, and under such constraint, if any, can that risk be mitigated? If the severity of the Risk itself is very high, and also the severity of constraint is very high then in such a situation management decision and past experience of the project manager and other stakeholders will be important. Assumptions are important inputs in identifying the risks, which should be documented. All stakeholders inputs for each risk from respective core process. In Risk Identification process, historical results of previous similar projects risk processes, should be studied to give inputs to the risk identification, as it can throw light about previous success, problems seen, how they were mitigated earlier for that type of risk. In Qualitative Risk Analysis process, stakeholders tolerances are explicitly considered as inputs, it is an important aspect to be considered as unless the stakeholders tolerances are known at least subjectively. E.g. If the stakeholders tolerance is very less, and the risk mitigation duration is high, or the risk occurrence probability is very low and its impact is very high to negatively affect the project success. In such situations, if the stakeholders tolerance is not known, and if it happens to be low, the output of the project and stakeholder satisfaction will be less. To overcome this flaw, ISO [2] Risk Management Process framework has suggested the stakeholder tolerance as the input to be incorporated in the Qualitative Risk Analysis. In the Risk Analysis process, Data gathering techniques are included. They are important to be explicitly mentioned as survey, questionnaire, interview, focus group discussions etc. This gives clarity to all the risk management team members with respect to the risk related data collection instruments and methods, instead of assumptions. It is equally important to communicate the outputs of the risk management processes as inputs to other relevant processes within the project life cycle. This is important as unless this has been done, no, other process will be effective towards its impact on the project success. Risk response Development process considers Insurance as one of the important process tool, the stakeholders need to consider for what aspects of the project the insurance can be obtained with respect to the derived risk framework for that project. Also attention needs to be given to insurance policy requirements such as premium and other clauses like their compliances to be adhered. Then a final decision for the individual project insurance can be considered. Risk Response Development process enables the updated Reserves as the output, consisting the financial implications of the individual risks at core process, task, and activity up to the risks at project level.

4.

5.

6.

7.

8.

24

9.

Risk Response Development process impacts the Contractual Agreements as the output, because only after the derived risk management plan, the project manager, business analysts will be able to accept, modify, update the requirements and accept or modify, negotiate and finalize the contractual agreements. 10. In Monitoring and Controlling Risk process, Additional Response Development as a process tool which enables the team to brainstorm and create more responses in addition to the existing, which can either reduce the negative risks or increase the positive risk. 11. Workaround as a process tool can be used as a process tool, in Monitoring and controlling Risk process. Workaround is a method or plan, sometimes used temporarily to achieve task goals, when usual or planned method is not working. 12. In Monitoring and Controlling Risk process, Additional Response Development as a process tool which enables the team to brainstorm and create more responses in addition to the existing, which can either reduce the negative risks or increase the positive risk. Case Study: This is a case of a project of an IT companys endeavor as a consultancy service to be provided to one of the major Insurance companies as a client. This project was to develop efficient and effective Risk compliant processes in the financial domain in order to meet the governments legal compliances. This case brings forth a lot of factors which are necessary to understand that why and how a Risk driven, Risk compliant project can be successful. This case has helped the researcher to understand, what additional factors to be incorporated into the Enhanced IT Project Risk Management Process Framework proposed by the researcher. The client was GenInsurance which is a very successful leading primary Insurance group in a European country. It required fulfilling the compliances introduced by Government to complete the legal necessities. With respect to accounting, reporting and risk management, SOX was necessary to be complied. Problem: To ensure the reliability, validity and accuracy of the financial and other information within the SOX compliance, GenInsurance required carrying analysis of underlying procedures and undergoing the reviewed risk management process. This assignment was handed over to one of the global IT service provider company as consultancy service. Solution: 1. The client and the consultant both implemented requirements in important operational units. 2. All financial statements and their sub-processes were analyzed, to identify which are the most impacting processes, tasks, activities. 3. An exhaustive process documentation method and risk assessment method was developed on the basis of the existing

IT architecture and already being used IT Risk Framework by the client. 4. Definition of overall process to provide sub-level interfaces which were quality compliant. 5. Transactional units, IT processes and operational units were mapped end-to-end into a framework. 6. Using the existing process documentation to define action plans, eliminate redundant process activities or tasks. Result: 1. The client built and integrated a compliance unit to complete the legal requirements of the government. The IT Consultancy helped the client in delivering adequate process documentation along with risk analysis for the important processes. 2. It increased the quality of existing processes, and increased reliability of financial reporting. Collaborative Approach: 1. The IT consultant should work collaboratively with GenInsurance and all important stakeholders. Following steps were used: 1.1 All process-owners involved from the beginning of the project and scope of work was communicated with all. 1.2 Field Experts critical reflection on project deliverables. 1.3 Regularly telephone conferences, presentations, work shops, consultants onsite presence can encourage a continuous project communication. 1.4 It was a four phase project 1.4.1 Phase I: To define a common methodology for the risk management framework in the organization and also to design an efficient business process methodology to be integrated with existing process models. This was the conglomeration of the existing Along with the existing risk management practices, risk framework, monitoring and process architecture, IT architecture, organization structure of the client was considered. The new Risk Management framework and process documentation needed client acceptance. It required more flexibility and hence a combination of COSO and CobiT was adopted with existing methods and risk tracking methods. 1.4.2 Phase II: In Phase II process documentation and risk analysis was done. In-depth analysis of the financial reports, income statements, and accounts was done by the project team. The project management has a lean project scope by focusing on key processes at six operational and five service units which were more importance from the compliance perspective or had more risk impact. Thus only required and most important from

25

risk perspective set of processes were targeted. 1.4.3 Phase III: These targeted processes were set at clients process benchmark structure. This consisted of process value chain and its level was grained so that it aligns with the entire objective of the risk management into consideration from top view to the detailed level of processes, tasks, activities. It overcame the issue of individual process level isolated risk management, and to focus on the quality of the complete business transactions. This helped on concentrating on required necessary limited number of key processes, sub-process, task, activities. 1.4.4 Phase IV: The consultant team accompanied the process owners and internal auditors, in new process walkthroughs, during this if any changes needed were implemented with respect to actual processes and proposed solution. Thus these new proposed processed were quality complied i.e. tested with risk controls. The test findings were analyzed and relevant were integrated into the system along with the client stakeholders approval. Major Objective was achieved by the following processes at macro level: Recurring, redundant processes were eliminated. Manual controls were automated. Weak process tasks were replaced by strong process tasks, and corrective and preventive mitigation actions were introduced. With the help of this proposed framework GenInsurance will be able to identify if the risk is to be covered or ignored or it is to be insured. Thus the Risk management based on end-to-end process chains made the risks coverage efficient. Additional problem from the Risk management Literature: The traditional IT Project Risk Management as practiced by the project mangers concentrates majorly on the negative effects of the Risk. Threats are managed as a part of the process, where as opportunities are overlooked or reactively solved. Integrated approach to threats and opportunities both will reduce negative risks and increase positive risks i.e. opportunities. Risk Definitions: It has been proposed that the definition of Risk is an umbrella term with two varieties of opportunities which is a risk with positive effect and Threat which is a risk with negative effect [1]. PMBOK defines Risk as project risk is an uncertain event, or condition that, if it occurs has positive or negative on a project objective, project risk includes both threats to the project objectives and opportunities to improve on those objectives . Threats and opportunities are qualitatively same, as they are associated with uncertainty, having an effect on the project success. There is a need of same process handling both threats and uncertainties. Some modifications are needed in the standard risk management approach with respect to the opportunities [6]. Risk Process: Many of the Risk Standards including PMBOK have more emphasis on the Risk Threats than on Risk opportunities in the Risk Management processes. Separate Risk opportunity Management may seem to a burden on project managers and which may not be achieved. The Opportunity process can be incorporated into the six risk management processes identified by PMI PMBOK Solution: The ISO [2] incorporates more emphasis on the risks which are positive, i.e. opportunities. It has been an explicit mention to the opportunities as the outcome of the ISO [2] Risk Management Process. Still more emphasis can be given to opportunities at all individual five sub-processes within the Risk management process. Researcher has incorporated the opportunities in all the subprocesses. 1. ISO [2] defines risk management as Risk Identification, Risk Estimation, Risk Response Development, and Risk Control. PMI PMBOK defines Risk Management as Risk Identification, Risk Analysis, Risk Monitoring and Control. Thus the important tasks identified by ISO [2] as well as PMI PMBOK are similar. The framework provided by PMI PMBOK and ISO [2] both identify and explain the Risk Management Processes, their inputs, tools required and outputs. Researcher did a comparative analysis of these process frameworks and found that both the processes are well established and have unique advantages to be offered to the projects which will adapt them. A framework is proposed after the comparative analysis of PMBOK and ISO [2], so that the new enhanced framework consists of best processes, inputs, tools, outputs from both the frameworks, and the project is benefitted from both methods. Enhanced IT Project Risk Management Process Framework: 1) Process Name: Risk Management Planning 1.1 Process Inputs 1.1.1 Project Scope statement Project Strategy 1.1.2 Schedule Management Plan 1.1.3 Cost management Plan 1.1.4 Communication Management Plan 1.1.5 Organisation process assets 1.1.6 Enterprise Environmental factors 1.2 Process Tools 1.2.1 Risk Planning Meetings and Analysis 1.2.2 Project Status Meeting -Project lifecycle status -changed requirements -review changed risks 1.3 Process Output 1.3.1 Risk Management Plan

26

2) Process Name: Identify Risk 2.1 Process Inputs 2.1.1.Product Description -Product Performance -Product Specification 2.1.2.Constraints 2.1.3.Assumption 2.1.4. Risk management Plan 2.1.5.Activity Cost Estimates review 2.1.6.Activity duration Estimate Review 2.1.7.Scope baseline 2.1.8.Stakeholder Register -Users view on risk factors and project teams views on risk factors 2.1.9.Cost management Plan 2.1.10.Schedule management Plan 2.1.11.Quality management Plan 2.1.12.project Documents 2.1.13. Enterprise Environmental factors 2.1.14.Organisational process Assets 2.1.15.Project lifecycle phase status

3) Process Name: Qualitative Risk Analysis 3.1 Process Inputs 3.1.1Risk register 3.1.2Sources of Risk 3.1.3Risk management plan 3.1.4 potential Risk Events 3.1.5 Project scope statement 3.1.6Stakeholder Tolerances 3.1.7Organisational process assets 3.1.8 Project lifecycle phase status 3.2 Process Tools Project Status Meeting -Project Lifecycle status -changed requirements -review changed risks 3.2.1Risk probability and impact assessment -Managements tolerance and flexibility with respect to high level complex, unquantifiable risks 3.2.2. Expected monetory Value 3.2.2Probability and impact matrix 3.2.3Statistical Sums 3.2.4Decision Trees 3.2.5Risk categorization, Risk Urgency assessment, Expert Judgement 1.2 Process Output 3.3.1Opprotunities to persue 3.3.2. Threats to respond to 3.3.3Opportunities to ignore 3.3.4Threats to accept 4) Process Name: Quantitative Risk Analysis 4.1 Process Inputs 4.1.1Risk register 4.1.2Data gathering and representative technique 4.1.3Risk management Plan 4.1.4Project Cost management 4.1.5Schedule Management Plan 4.1.6 Oraganisational process assets 4.1.7 Project lifecycle phase status 4.2 Process Tools Project Status Meeting -Project Lifecycle status -changed requirements -review changed risks 4.2.1Quantitative risk analysis and modeling technique 4.2.2Expert Judgement 4.3 Process Output 4.3.1Risk Register Updates

1.2 Process Tools: 2.2.1 Project Status Meeting -Project Lifecycle status -changed requirements -review changed risks -Documentation -Reviews 2.2.2.Information gathering technique -concordance and discordance on risk factors by users and project teams perspectives, and to come to consensus of the mutually agreeable risks 2.2.3.Interviewing 2.2.4. Historical Results 2.2.5.Checklist Analysis -Severity Analysis -Views of relevant stakeholders in deciding the impact of the risk on project 2.2.6.Assumption Analysis 2.2.7.Diagramming technique 2.2.8.Swot Analysis 2.2.9.Expert Judgement 2.2.10. All stakeholder training - Generic processes to build trust, sense making, organization culture to better suited to operate high level of uncertainty

1.3 Process Output 2.3.1 Risk Register 2.3.2. All sources of Risks 2.3.3. Potential Risk Events

27

5) Process Name: Plan & Development Risk Responses 6.2.8. Status meetings 5.1 Process Inputs 5.1.1 Risk register 5.1.2 Opprotunities 5.1 3. Threats 5.1 4. Risk Management Plan 5.1 5. Project lifecycle phase status 5.2 Process Tools Project Status Meeting -Project Lifecycle status -changed requirements -review changed risks 5.2.1. Strategies for negative risks or threats 5.2.2. Contacting clients 5.2.3. Strategies for positive risks or opportunities 5.2.4. Contigent response strategies 5.2.5. Expert judgement 5.2.6. Insurance 5.3 Process Output: 5.3.1. Risk register updates 5.3.2. Risk Management Plan 5.3.3. Risk-related contract decisions 5.3.4. Inputs to other processes 5.3.5. Project management Plan 5.3.6. Contigency Plan 5.3.7. Project document updates 5.3.8. Reserves 5.3.9. Contractual Agreements 6) Process Name: Monitor and Control Risks 3.4 Process Inputs: 6.1.1.Risk Register 6.1.2.Risk Management Plan 6.1.3.Project management Plan 6.1.4.Actual Risk Events 6.1.5.Additional Risk Identifiation 6.1.6.Work Performance information 6.1.8.Performance reports 6.1.9. Project lifecycle phase status 3.5 Process Tools Project Status Meeting -Project Lifecycle status -changed requirements -review changed risks 6.2.1.Risk assessment 6.2.2.Workarounds 6.2.3.Risk Audits 6.2.4.Additonal response Development 6.2.5.Variance and Trend Analysis 6.2.6.Technical performance measurement 6.2.7.Reserve Analysis 3.6 Process Output 6.3.1. Risk register updates 6.3.2. Updates to Risk Management Organisational process assets updates 6.3.3. Change requests 6.3.4. Project management plan 6.3.5. Project document updates Conclusion: An IT project Risk management is one of the critical areas to impact the project success. To manage the project risks well, many risk management principles, practices, frameworks are available. The researcher studied the already widely accepted risk management framework by PMI PMBOK and ISO [2]. It was found that both of these risk management framework have their own strengths in order to drive the projects towards success. Some initial literature with respect to IT project risk management and successful risk management project case was studied by the researcher. It was observed that, still there is a scope for enhancements to be done in the above two frameworks. Researcher proposed a new enhanced framework for IT Project Risk Management, based on the best practices, processes proposed by PMI PMBOK and ISO [2], it was conglomerated with the found gaps in the studied, projects risk management. Future Scope: Further development of the proposed Enhanced IT Project Risk Management to the sub-process, task-level, activity-level. To further finding the gaps in other existing widely used IT Project Risk Management and further development of new frameworks based on literature review and industry project case studies.

REFERENCES
[1] Kalle Lyytinen, Daniel Robey, Learning failure in Information Systems development, Info Systems J, 9, pp. 85-101, 1999. [2] Stephen Du, Mark Keil, Lars Mathiassen, Yide Shen, Amrit Tiwana, Attention shaping tools, expertise, and perceived control in IT Project Risk Assessment, Decision Support Systems , vol. 43, no. 1, pp. 269-283, Feb 2007. [3] Modernisation: clearing a pathway to success, Standish Research Report, Issue 14 Dec. 2010. [4] James J. Jiang, Gary Klein, T. Selwyn Ellis, Measure of Software Development Risk, Project Management Journal, The Journal of PMI, vol. 33, no. 3, Sep 2002. [5] Project Risk Management Process Framework, PMI PMBOK. [6]David Hillson, Extending the risk project to manage opportunities, Elsevier ScienceDirect International Journal of Project Management, vol. 20, pp. 235-240, 2002. [7] K.A. ARTTO, PUTTING PROJECT RISK MANAGEMENT INTO PERSPECTIVE Fifteen years of project risk management applications - where are we going?, In Managing Risks in Projects, Proc. IPMA Symp, Project Management, part 1 , Sep 1997. (Conference proceddings) [8] Roger Atkinson, Lynn Crawford, Stephen Ward, Fundamental uncertainties in projects and the scope of project management, ELSVIER, SCIENCEDIRECT, International Journal of Project Management, vol. 24, no. 8, pp. 687-698, 2006.

28

(http://dx.doi.org/10.1016/j.ijproman.2006.09.011) [9] Mark Keil, Amrit Tiwana, Ashley A. Bush, Reconciling user and project manager perceptions of IT project risk: A Delphi Study,Info Systems J , vol. 12, pp. 103119, 2002. [10] Flavio Roberto Souza dos Santos, FEMA and PMBOk applied to Project Risk Management, Journal of Information Systems and Technology Management, vol. 5, no. 2, pp. 347-364, 2008. [11] Tzvi Raz, Aaron Shenhar, Dov Dvir, Risk Management, Project Success, and Technological Uncertainty, R&D Management, vol. 32, 2, pp. 101-109, 2002. [12] Y.H.Kwak, J. Stoddard, Project Risk Management: Lessons Learned from Software Development Environment, Elsevier ScienceDirect Technovation , vol. 24, pp. 915-920, 2004. [13] H. Steyn, Project Management applications of the theory of constraints beyond critical chain scheduling, Elsevier ScienceDirect International Journal of Project Management, vol. 20, pp. 75-80, 2002. [14] T. Raz, Use and benefits of tools for project risk management, ELSEVIER Pergamon International Journal of Project Management, vol. 19, pp. 9-17, 2001. [15] http://www.brighthub.com/office/project-management/articles/48245.aspx Pradnya Purandare is Master of Computer Management (M.C.M.) (1996) & B.Sc. (1994) from University of Pune, India. She has been into academics since past 14 years. She has worked as lecturer in Pune University Post Graduate colleges. She is currently working as Assistant Professor in Symbiosis Centre for Information Technology (SCIT) since 2004. Her research and review papers have been published in various conferences and journals of national and International level. She recently participated in a sponsored research project on project management for PMI, India. She is also working as a reviewer for SCIT journal. Her research interest areas are IT Project Risk Management, Software Project Management, Software Engineering, Data Warehousing and Data Mining. She is persuing doctoral research is IT Project Risk Management from SIU, Pune, India.