(Author note: This paper published here anonymously)
In reality, challenges and difficulties are remained for applying effective risk management process in the software development process. Nevertheless benefit from using software risk management processes, techniques and tools are profound.
Organisation culture is very important for effective risk management process to be successful. Company should see the value that effective risk management provides to succeed a project rather see as an additional cost.
Explicit risk management is establishing its ground in industrial software development projects. However, there are only few empirical researches analyse adopting explicit risk management methodology to the industrial contexts. 
This paper examines effectiveness of systematic risk management method, namely the Riskit method into a billion dollar company FoxMeyer Drugs for SAP (R/3) ERP implementation project. Additionally, our illustration has shown that Riskit method is a realistic, value-added, understandable and useful practice for managing risk for software projects.
Dictionary definition for risk is “the possibility of loss or injury”. This definition highlights the negativity that often associates with the risk and suggests that uncertainty is involved. On the other hand, positive risks or opportunities that may also result in a positive thing happening in the project. 
A general definition of a project risk therefore, is an uncertainly that can have a negative or positive effect on meeting project objectives. The objectives of the risk management may consider as minimizing possible negative risk while maximizing possible positive risks.
The Project risk management is a series of activities such as planning, identifying, analysing and acting on the risk throughout entire project lifecycle repeatedly in order to meeting project goals. However, risk management is often gets overlooked but benefit from the appropriate project risk management results significant improvements in the eventual success of the projects, effective risk management results in fewer issues and these also could be resolve very quickly. Risk management for the project can helps stakeholders to understand project nature and strengths and weaknesses of the project team members and associated resources. Poor risk management is likely cause of project setback and failure. 
There are many histories of IT project failure due to different reasons e.g. 50% of the IT projects deemed failures (Meta Group), 28% of IT projects are cancelled / not implemented (Standish Group), 75% exceeded time deadlines and more than 50% substantially exceeded budget (KPMG), Only 33% of outcomes were viewed as positive (Boston Consulting Group)  and this evidence had indicated that risk have not managed effective fashion. Although some project manager may claim to have adopted risk management process but there would be some evidence that they may not managing risks systematically. They may have addressed technical risk but there are other risk areas such as market and financial risk that are also a critical for successful software project.
Nevertheless, the degree of risk also depends on complexity, size, culture, scope creep, poor understanding of the customer issue and unclear requirements and lack of resources are common in software development projects. So we need an integrated risk management processes.
As we see on following table (Figure 1), the percentage of failed projects without proper risk management process ranked third.
Figure 1: Percentage of failed projects per failure factor 
Indeed, all industries are facing challenges coping with current economic fallout due to credit crunch; despite we should not take risk management lightly as redundant cost to be cut in the difficult time. Rather industry should use the benefit that effective risk management provides to ensure that organisations are capable to fight uncertainties and emerge in best possible position in the future. Due to high levels of uncertainty surrounding us today, risk management is absolute needs now than ever. Therefore, we should not avoid risk management process to save money but to see as major part of the greater solutions.
Purpose of this pater is to develop an integrated risk management framework based on Riskit method and applies its distinctive features to FoxMeyer Drugs.
This paper is organised as follows. Section 2. Presents literature review in key terminology in one place with terms, models, approaches are highlighted and discussed. This section is also discussed our preferred risk management methodology called Riskit and motivation for selecting the Riskit method and detail outline its underlying principles and associated process with analysis graph and pareto ranking technique. Section 3. Presents the case study for FoxMeyer Drug. Section 4. Presents details discussion on FoxMeyer SAP implementation issues and illustrated Riskit method to justify risk mitigation. Section 5. Presents summary with conclusions and discusses further development plans.
Project risk may arise outside of the control of project team and project team must realize future risk before they occur. This is an art of risk management. It is not all risks are unseen or out of project team’s control, many problems can be seen ahead and this should be resolved through a proactive risk management process.
We have reviewed many journals, case studies and web resources to understand risk management definition, terms and associated processes, risk factors in various models and methods. Here are few such examples of various relative researches:
Boehm (1998) proposed a risk management framework, which helps to identify the primary sources of risk, analyse, and resolve them. This risk management framework can be integrated into the Original Spiral, or the Win-Win Model. 
Hall (1998) approached risk management by identifying four different factors that have the potential to alter the expected. These are People, Process, Infrastructure and Implementation factors 
Karolak (1998) took a Just-In-Time approach for risk management in software engineering. The Just-In-Time approach attempts to minimize the amount of risks involved while optimizing the contingency strategies for problematic situations. 
Software Engineering Institute’s (SEI, 1999) provided a comprehensive risk management framework comprising of the three groups of practices: such as Software Risk Evaluation, Continuous Risk Management, and Team Risk Management.
Turner (1999) suggested expert judgment, plan decomposition, assumption analysis, decision drives and brainstorming for identification of risk factors effectively in a project. 
Foo and Murugananthan’s (2000): proposed a questionnaire based approach for analysing risks to provide a quantitative assessment. The approach can be used to quantify risk elements and use them to estimate a normalized value of the overall project risk. This model called the software risk assessment model (SRAM) is based on the use of situational factors to predict project risks. 
Kontio (2001) proposed the Riskit methodology, which provides a complete conceptual framework for risk management using a goal and stakeholder-oriented approach. It attempts to manage risks by capturing the intentions of stakeholders in the risk management process. 
Some models require detailed quantitative information such as Foo and Murugananthan’s [ 25], Rainer et al, , Dey 
that is not usually available in the planning phase and the adoptability of such models to real project risk analysis was limited as organisation participating in the project has an issue with making accurate decisions. The issues are poorly defined and vague and thus required a subjective evaluation that classical models are unable to handle. 
Above methods were much matured compare to recent methods, recent advancement primarily propose risk analysis methodologies, not a complete risk management framework. Here we outline some recent contributions in this area as follow:
Deursen & Kuiper (2003): proposed a novel risk assessment method by identifying the dissimilar primary and secondary facts in a project. The primary facts were achieved by analyzing the system and secondary facts were achieved by interviewing stockholders, reviewing contact documents, Project plans, requirements specification and design documents. Finally, both facts were taken in tandem and compare to observe whether the risks perceived from both the angles are consistent with each other 
Tiwana and Keil (2004): developed a handy software risk management methodology that enable project managers to quickly assess some of the important project risks and effects. This methodology and the questions in it were developed from data collection from the IT managers of 60 companies. 
Baccarini (2004): identified and prioritized IT project risks through empirical research and suggested possible responses, but did not provide any framework for software risk management. 
Roy (2004): it is an extension of AS/NZS 4350 standard. It categorized risk management activities into the business domain and the operational domain. It performed different activates such as identifying the stakeholders, risk factors, constructing risk free model, probabilities of risk events, developing the action plans and monitoring the progresses. 
Misra Et Al (2005): used by project managers to model and control risk in software projects. It offers project managers to perform means-end analysis where uncovering the structural origin of risk in the project and how root causes of such risk can be controlled from early stages of the project lifecycle. This approach addressed limitation of many existing risk management models by exploring the strategic dependencies between the actors of a project and analyzing the motivations, intents, and rationale behind the different entities, and activities in a project. 
Unfortunately, many of these models discussed above are limited by the lack of empirical evidences supporting them. This is a significant area in which future work should be aimed.
Reasons for use Riskit method
We have selected Riskit method over others due to its simplicity, flexibility and effectiveness of risk management process. We used Riskit method to analyse project risk in this paper. Riskit is a risk management method was developed by professor Jyrki Kontio as a part of his doctoral dissertation and this method has been widely use in corporate software risk management. For an example, Nokia and Daimler Chrysler have incorporated key aspects of the method into their risk management practice. 
Riskit method was based on sound theoretical foundation and focuses on qualitative understanding of risks before their possible quantification. Riskit method offers a defined process for carry out risk management. This methodology is favoured different techniques and guideline and Riskit does not restrict use of other software risk management methodologies.
Riskit method is designed for greatly low overhead and complexity for real and time constrained projects. As it was designed with more solid theoretical foundations, it avoids many limitation and issues seen in other common methodologies such as use of Software Risk Evaluation (SRE) method [1,10], biased ranking table and expected value calculation .
An older edition of the Riskit methodology has been empirically evaluated in a limited numbers of case studies [11,12,13]. Current edition of the methodology (version 1.00) has been improved based on the feedback received from different case studies and evaluations carried out industry and movement origination. 
Riskit methodology offers project team with the accurate and timely dissemination of project information, opportunity and risk to diverse stakeholders thereby enabling to make critical decisions for the overall success of the project. Riskit offers a systematic management of project, starting from identification, analysis of risk to the monitoring and controlling. 
Riskit has been widely presented in other publications [14,15,16,17,18]. The Riskit Method comprises of the following features:
Complete Process Definition – The Risk Method has a comprehensive process definition that supports risk management activities throughout the project.
Goals and Stakeholders – It maintains links between risk and stakeholder explicitly, an extension of Boehm’s Win-Win risk management approach that focuses on stakeholder’s goals.
Riskit Analysis Graph – A graphical formalism that is used to define the different aspects of risk more formally in order to achieve better communications and deeper, qualitative understanding of risks.
Pareto Ranking and Utility Loss – It incorporates utility theory components into a straight-forward approach.
Complete Process Definition
Riskit method has a complete defined process as shown in Figure 2.
Figure 2: Overview on Riskit Process
Goals and Stakeholders
In the Riskit method, definition of loss depends on expectations, which in turn depend on stakeholders of the project. The stakeholders influence the definition of loss in a project since different stakeholders view outcome differently. As shown in Figure 3, the Riskit process includes a specific step for analysing stakeholders’ interests and how they link to risk. When risks are defined, their impact on the project is described through the stated project goals. This allows full traceability between risks and goals and on to stakeholders.
Figure 3: Riskit Method – Definition of risk
Risk Analysis Graph
Riskit method supports unambiguous definition of risks using the Riskit analysis graph as shown in Figure 4. In addition, the graph allows visual and formal documentation of risks which result in better communications and a comprehensive understanding of the risks’ context.
Figure 4: Riskit Method – Conceptual view of the risk elements in the Riskit analysis graph
Pareto Ranking and Utility Loss
To perform prioritization, most risk management approaches rely on risk estimation approaches that are either impractical or theoretically questionable. For example, the expected value calculations (i.e., risk = probability * loss) are often impractical.
Because accurate estimates of probability and loss are seldom available and it is difficult to account for multiple goal effects and for a non-linear utility function.
Riskit Method adopts Pareto ranking technique, illustrated in Figure 5, which provides a reliable and consistent ranking approach that only ranks risks as far as the input data allows.
Figure 5: Riskit Method – Pareto Ranking Technique
FoxMeyer Drug was one of the largest pharmaceutical distributors in the United States with annual sales of US$ 5 billion and daily shipment of half a million items in 1995. The company’s core customers were retail chains, institutions and independent pharmacies. In order to provide national coverage throughout the United States, FoxMeyer had 25 distribution center and was engaged in franchising and wholesaling to franchised stores.
For FoxMeyer to be competitive in the market, their business strategy includes:
Reduce cost through economy of scale; yet maintain high standard in quality
Increase operational efficiency through automating physical warehouses and implementing supply-chain information management system
Introduce other value-added services such as complementing distribution activities with marketing programs
In 1993, the management of FoxMeyer embarked on a major IT project named Delta III which it said would increase efficiency by minimizing redundancy, streamlining operations as well as providing responsive customer services and optimal analytics on supply and demand. FoxMeyer engaged Andersen Consulting to implement and integrate SAP (R/3) and Pinnacle warehouse-automation systems. The selection was based on the following factors:
SAP (R/3) is a well-known ERP (Enterprise Resource Planning) software which includes several modules in accounting, finance, logistics HR, sales and distribution etc that can help companies integrate and streamline their business processes.
Andersen Consulting had a large portfolio of IT solutions in various businesses worldwide. They had IT consultants dedicated for different business domains and functions according to their clients’ needs. Moreover, the company’s experience in SAP implementation had earned its reputation over years.
Delta III project was considered to be a top-down approach driven by top management covering the entire supply chain from end-to-end which comprised of warehouses, inventory control, customer service, marketing, strategic planning, information system, shipping and handling. The timeframe for Delta III project was an underestimation considering its wide range of functions to be implemented. For SAP, R/3 was the first implementation in the pharmaceutical industry and wholesale distribution business. The budget for implementing SAP (R/3) was US$ 65m which included:
US$ 4.8m client/server computer system from Hewlett Packard,
US$ 4m SAP software,
US$ 18m for a new 340,000 square-foot computerised warehouse, and
Several millions for consultation from Andersen Consulting
The project was projected to save US$40m per annum for FoxMeyer.
In 1994 to 1996, there were several events which eventually brought FoxMeyer to bankruptcy even before the projected saving was realized. The following table (Table 1) summarized the events, in chronological order, which had taken place from the start of Delta III project.
Commencement of Delta III project; SAP (R/3) was purchased without proper evaluation.
SAP (R/3) lacked of many requirements to meet business needs.
FoxMeyer signed a large distribution contract with University Healthcare Consortium (UHC) which required them to add 6 warehouses
Schedule and cost were affected by the extension of project scope.
The sales histories of the customers were inaccurate due to data error
Error in delivery; Inaccurate analysis of supply and demand
Employees were resistance to the new ERP implementation as most of them were not trained to use the new software. Morale of the employees was low due to the speculation that they might be laid off after the ERP system commenced.
Lack of ownership from the end users. Inventory was damaged due to mishandling by the employees.
SAP (R/3) underperformed; handling 10,000 transactions daily as compared 420,000 transactions by the legacy system.
Overall delay in the supply chain which affected their service and reputation.
Some modules testing were omitted due to tight schedule.
Poor quality in functionality; Incurred additional cost to manually resolve some parts of the orders.
FoxMeyer covered uncollectable costs on customer orders and inventory problems along with investment expenditures on the ERP implementation.
FoxMeyer filed bankruptcy
Table 1: Summary of the events and effects taken place from the start of Delta III project
These events had happened without proper risk assessment being conducted at the initial stage of the project. The unforeseen costs incurred were:
More than US$ 50m project overrun, with the final implementation bill of more than US$ 100m
US$ 16m correcting data errors caused by human erroneous
US$ 34m charge to cover uncollectable shipping and inventory costs
The failure of Delta III project was due to several other reasons:
No consideration of other consultants’ advice – The project went ahead despite Woltz Consulting, a Chicago-based firm, who warned FoxMeyer that it was unrealistic to plan an 18-month schedule for the entire ERP implementation.
Lack of contingency planning – there was no contingency plan to manage changes in the business operations. E.g. one of major customers of FoxMeyer, Phar-Mor Inc., declared bankruptcy shortly after they launch SAP.
Despite events which showed signs that the project was at risk, the project was stretched to the extent which led to FoxMeyer’s bankruptcy. Finally, McKesson Corporation bought over FoxMeyer for US$ 80m in late 1996. In 1998, the trustee of FoxMeyer filed lawsuits of US$ 500m each against SAP and Andersen Consulting. Further investigations were launched to identify the root causes of project escalation. A model of factors suggests that escalation of the project was promoted by combination of project, psychological, social and organisational factors.
In FoxMeyer’s context,
Delta project was projected to save a lump sum of US$ 40m annually. This enormous savings had pushed FoxMeyer’s senior management to continue with the project although some technical issues were encountered during the implementation.
SAP and Andersen Consulting were reputable in successful ERP implementations. Likewise, it was perceived that the project could make it through. Nevertheless, many people failed to understand that in reality there is no interrelation between the projects’ outcome. In addition, abandonment of the project would high likely give a negative image of SAP and Andersen Consulting.
The senior management being advocates of the project had unknowingly caused project escalation.
Certainly, a proper risk management framework would have prevented escalation of the project and saved FoxMeyer from bankruptcy.
The failure of Delta III project can be viewed from several perspectives, based on the risk factors affecting enterprise-wide information management projects:
In general, it is believed that commercial off-the-shelf software like SAP (R/3) offers significant savings and maintenance in the long term. Such software would require a high degree of customization in order to fit seamlessly into a specific business process. Hence, the key is to reengineer the business process and avoid customization. FoxMeyer, however, was unable to redesign their business processes to be consistent to the software specifications.
Several data errors were encountered when SAP (R/3) was rolled out in the new warehouses. There was an evident on lack of data standardisaton in the ERP system. Moreover, integration between SAP (R/3) and the warehouse-automation systems would increase the likelihood of data integration problems which could have been left undiscovered during system testing.
FoxMeyer was over dependent on Andersen Consulting in the implementation as they did not have in-house personnel with the necessary skill to handle the project.
Since SAP was new to the wholesaling industry, inexperienced consultants from Andersen tapped on the opportunity to learn SAP technology business.
Management structure and strategy:
There was a change in management strategy and support. In early 1996, the CEO of FoxMeyer, who was seen as a strong supporter of the project, was asked to resign due to the delays in the new warehouse and realizing the projected savings of SAP implementation.
Furthermore, the management was reluctant to acknowledge the system problems and agreed to have 90 days early implementation even though the system was not fully tested.
User involvement and training:
There was lack of user involvement during the initial stage of the project as there was low participation from the end users in the analysis and design process.
Because of this, user requirements were not completely addressed and there was no training for the end users. Thus from the end users’ viewpoint, they did not gain ownership for the project.
The automated warehouse had been perceived to eliminate unnecessary manual labour and lay off employees. This dampened the employees’ morale, which in turn resulted in mishandling of inventory.
SAP (R/3) was considered to be an unfit for FoxMeyer as it was originally designed for manufacturing companies. This eventually led to an undesirable outcome – SAP (R/3) could only handled 10,000 orders as compared to 420,000 orders by the legacy system.
Instead of rolling out the new system in phases, high risk was imposed by the big-bang approach to implement and integrate SAP (R/3) and Pinnacle automated-warehouse systems simultaneously, particularly when both systems were part of the core business.
The scope of the project was enlarged after FoxMeyer signed a contract with UHC to implement a US$ 18m computerised warehouse project without proper risk management which is an essential part in project management.
Pre-implementation testing was inadequate due to tight project schedule. Status of the project status was not timely managed to ensure that it followed according to schedule and budget.
We used the Riskit method for the risk analysis as it is considered to be effective and easy to understand. Using the Riskit method, the risks identified earlier can be classified into risk factors and events and results documented in the Riskit analysis graph as shown in Figure 6. The Riskit analysis graph, illustrated with possible relationships between the risk elements, is a graphical formalism which enables better communications and deeper qualitative understanding of risks.
Figure 6: Riskit analysis graph on FoxMeyer’s case study
The Riskit analysis graph maps risks to utility loss and therefore effectively provides an overview of the affected goals in the project. From the graph, some risk factors can be seen to influence multiple goals.
Another feature of the Riskit method is the Riskit Pareto ranking technique which uses two-dimensional space to position risk scenarios by their relative probability and utility loss. First, risk scenarios are ranked by probability as shown in Figure 7. At the same time, stakeholders would rank the risk scenarios by utility loss based on their individual perspectives as shown in Figure 8.
Figure 7: Risk scenarios ranked by probability
Figure 8: Risk scenarios ranked by utility loss
The two ordinal metrics are combined together to construct the Riskit Pareto table as shown in Figure 9. A Pareto efficiency of the risk scenarios over other scenarios can be easily assessed from the table; a risk scenario is Pareto efficient over all other scenarios if it is located at the upper left-hand corner in the table.
Figure 9: Riskit Pareto table by probability and utility loss
From the Riskit Pareto table, risk scenario of “SAP R/3 unable to handle large transaction” is considered to be Parento efficient. The remaining scenarios can only be partially ranked based on the available information. The significance of partial rankings is that they enable effective management of risk scenarios through relative prioritisation.
Using the Riskit method, stakeholders such as project managers, customers, senior management, and developers can be involved to rank risks with respect to their utility loss. Figure 2 illustrates the use of the Riskit Pareto ranking technique. The Riskit method takes account of utility loss which in reality would not be able else difficult to achieve using mathematical calculation.
Since risk scenarios can occur at any activity in the project, we recommend associating them to the corresponding activities in the project network diagram to caution the project team specifically on the risk scenarios which under the critical paths in the project.
It is worth to note that ranking by utility loss is subjective and it varies based on the experiences of the stakeholder which might be inaccurate. In other words, ranking of utility loss by an inexperienced stakeholder may differ widely when compared to an experienced stakeholder. Hence, we can conclude that the stakeholders’ utility loss changes over time. Because of this, we suggest to develop pilots for large-scale system implementation projects. This enables the stakeholders as well as new project members to have a good understanding on the possible risks that the project may encounter and at the same time, it be can minimize end-users’ resistance by allowing them to have a feel of the system at small scale.
Apart of employment of a systematic risk management process to manage risks at project level, we suggest that the management of FoxMeyer should create a risk-aware culture in the organisation to respond to risks which are otherwise fuzzy. Fuzzy risks such as human factors and cultural settings of an organisation which are often overlooked in risk management because they are ambiguous and difficult to detect. In order to establish such awareness, we think that FoxMeyer should focus on the following key areas:
Enhance competence and integrity – FoxMeyer should establish trust in the employees by addressing their competency and integrity. Employees should be well-trained to use the ERP software and manage concerns of the end users. When people at all levels and in all areas of an organisation are bombarded with new systems, new processes, new products, and new initiatives, risk capable organisations focus on supporting competency development, listening to concerns about training and knowledge, while being totally committed to the value of integrity.
Innovate and manage the basics – The senior management of FoxMeyer should identify the current risks inherent in the processes that support the business and build in various controls before they embarked on the new ERP implementation. Innovation without managing the basics is high risk, short-term strategy.
Resilient – FoxMeyer should have changed the implementation strategy when they encountered intermittent interference to the business to minimize risk. When Phar Mor, one of the major customers which attributed to 15% of FoxMeyer’s business, declared bankruptcy, there should be a contingency plan to manage and respond to this change instead of carrying on with the implementation. Resilient means to have a backup plan and be agile to change strategy to mitigate risks.
Numerous risk scenarios can be identified based on different risk identification techniques and what-if analysis. Typically, however, not all risk scenarios can be identified in the project and of those identified, risk scenarios with higher probability will be addressed first. Like the black swan which occurred during the financial crisis, unidentified risks posed greater danger than anyone can imagine since they are uncontrolled. With this in mind, a risk management framework should always include contingency plans to make up for the unforeseen circumstances.
Based on our analysis and discussion above, here we defined some lessons learned. The following points can be applied to any other projects as are largely independent of the case study.
Explicit and systematic software risk management is recognized as useful: Prior to Riskit’s implementation, project managers perform risk management by based on individual project manger’s idea and instinct. There were no systematic and proven techniques for risk management. However, explicit and systematic process results as value add to project member’s daily practices. 
The distinctive features of Riskit were recognized as practical and understandable: Brainstorm and checklist during risk identification allows adjoining the experience of the project members and simultaneously systematically checks for standard risk factors. 
In the risk analysis phase, the Riskit provided effective discussion and understanding regards to projects risk. Pareto table allows us to take in to consideration of the probability and the utility loss effectively during selection of the most important risks. 
Monitoring is one most important activity: risk monitoring is a critical activity for proactive risk management process. Technique used for monitoring should be carefully selected to avoid information overload as it is the activity that perform very frequently. 
Ensuring seamless integration of risk management activity throughout the project lifecycle: regular project meetings should be conducted to discuss risk management activity. Early detection of risk prevents major loss in the later stage of the project and integration should influence for appropriate documentation. Developers should not view risk management process as a burned rather consider as a part of routing work. 
Ensuring commitment from management for implementing risk management: it is very important that upper management and project managers supports project risk management process. They need to fully aware for project benefit for proper risk management activities. 
Take ownership of risk management process: it is important that project members including project manager take ownership of appropriate process and if anything goes wrong with that process then person-in-charge will be responsible for answer to the management. Thus, we could ensure that risk management process has been considered seriously effectively implemented risk management process thought the project lifecycle. 
Various risk identification techniques such as brainstorming, checklists, and questionnaires can be employed in the case study. Although each technique has its pros and cons, risk identification mainly rely on the experiences elicited from different projects and therefore the key is to capture risk knowledge and apply it to future projects.
Without proper risk management process, organisations cannot determine nature of the risk and its real impact, leaving them for greater loss, vulnerable to the threats and regulatory compliance. The risk management process is an ongoing cycles of processes with repeat checks, detects and acts, and certainly not a onetime affairs.
Current methods available today are not comprehensive enough for managing risk in software development as they deal with specific types of risk. Therefore, we need effective software development methods that provide analysis of software risk management issues from the developer perspective with active involvement of stakeholders along consideration of both qualitative and quantitative risk factors as well as integrating the risk management process with the software development life cycle. 
No doubt that effective software risk management is a daunting task. Organisations around the world have been realized now that effective risk management process has proven to be successful; in contrast, others who have failed with this effort were unsuccessful.
The complexities of the software projects introduced many risks that need to tackle diligently to avoid common draw back as many failure projects. The awareness, organisation culture and attitudes towards risk management tasks are multiply challenges for implementing a risk management strategy.
So far, many risk management processes have been created to assist organisations but integrating the process to organisation was not so successful. [22,23]. Theoretical aspects of processes must bring together with practical challenges for the organisation to implement risk management successfully. Effective risk management process will thrive by changing corporate culture to motivate the individual. Cultural changes need time and reiterations before there are firmly embedded into organisation. [22,23].
In this paper, we presented a case study of implementing risk management at FoxMeyer Drugs. The objectives of the case study were to analyse the usefulness and adequacy of Riskit method and apply the method to FoxMeyer Drugs and improve risk management process in general. In contrast, the objectives were to analyse the cost and benefit of Riskit in an industrial context. Results showed above that Riskit method was a practical and understandable risk management method. Methods for describing risks scenarios and for selecting the most important risks in Pareto ranking technique were highly effective.
As the costs for risk management were seen as acceptable, the experiences from this case study can be used to improve risk management at FoxMeyer Drugs and thus increase its cost effectiveness. Riskit can be useful for every software project who considering the implementation of explicit risk management process. 
 Freimut, B., Susanne, S., Kaiser, P., Kontio, J., & Kobitzsch, W. (2001). An Industrial Case Study of Implementing Software Risk Management. ACM SIGSOFT Software Engineering; Notes ACM SIGSOFT Software Engineering, 26(5,) 277 – 287.
 Callaghan, J. (2006). Project Risk Management – Risk Advisory Services.
Retrieved Mar 01, 2010 from http://www.isaca.org.hk/document/KPMG%20Presentation_ISACA_101006ppt2.pdf
 Roy, G.G. (2004). A Risk Management Framework for Software Engineering Practice, Proceedings of the 2004 Australian Software Engineering Conference (AAWEC ’04), IEEE Computer Society, April, Melbourne, Australia.
 Misra, S. C., Kumar V., and Kumar, U. (2005). Modeling Strategic Actor Relationships to Support Risk Analysis and Control in Software Projects. Proceedings of the 2005 International Conference on Enterprise Information Systems, Miami, Florida, USA, May 25-28, 288-293.
 Rainer, R.K., Snyder, C.A. and Carr, H.H. (1991). Risk analysis for information technology,
Journal of Management information systems, 8 (1), 129-47
 Turner, J.R. (1999). Handbook of Project-based Management. New York : McGraw Hill
 Baccarini, D., Salm, G. & Love, P.E.D. (2004), Management of Risks in Information Technology Projects. Industrial Management and Data System, 104(4), 286-95.
 Dey, P.K, Kinch, J., & Ogunlana, S.O. (2007). Managing Risk in Software Development Projects: A Case Study. Industrial Management & Data Systems, 107 (2), 284-303
 R&D Ware (2010). Riskit – a Method for Risk Management. Retrieved March 02, 2010 from http://www.rdware.com/en/riskit-method
 BMP (2010). Best Manufacturing Practices, Software Risk Evaluation (SRE) Ver 0.1, Retrieved on February 10, 2010 from http://www.bmpcoe.org/library/books/sre/index.html
 Englund, H. (1997). A Case Study to Explore Risk Management Method. Kunglika Tekniska Högskolan, Stockholm, Sweden. Masters thesis.
 Kontio, J. & Basili, V.R. (1997). Empirical Evaluation of a Risk Management Method. Proceedings of the SEI Conference on Risk Management. Software Engineering Institute. Pittsburgh, PA.
 Kontio, J. H., Englund, & Basili, V.R. (1996). Experiences from an Exploratory Case Study with a Software Risk Management Method, Computer Science Technical Reports. University of Maryland. College Park, Maryland.
 Kontio, J. & Basili, V. R. (1997). Empirical Evaluation of a Risk Management Method, Pittsburgh, PA, Software Engineering Institute. Proceedings of the SEI Conference on Risk Management.
 Kontio, J. & Basili, V. R. (1996). Risk Knowledge Capture in the Riskit Method, Proceedings of the 21st Software Engineering Workshop. Greenbelt, Maryland, NASA.
 Kontio, J. (1997). The Riskit Method for Software Risk Management, version 1.00., College Park, MD, University of Maryland. Computer Science Technical Reports. Retrieved March 03, 2010 from http://mordor.cs.hut.fi/~jkontio/riskittr.pdf
 Kontio, J., Englund, H., & Basili, V. R. (1996). Experiences from an Exploratory Case Study with a Software Risk Management Method. College Park, Maryland, University of Maryland. Computer Science Technical Reports.
 Kontio, J., Getto, G., & Landes, D. (1998). Experiences in improving risk management processes using the concepts of the Riskit method. Proceedings of the Sixth International Symposium on the Foundations of Software Engineering, 163-174.
 Joe Nocera (2009). Risk Management – What Let to the Financial Meltdown. Retrieved March 01, 2010 from http://www.nytimes.com/2009/01/04/magazine/04risk-t.html?_r=1
 Schwalbe, K (2010). Managing Information Technology Projects. Sixth International edition. Singapore: Cengage Learning Asia Pte Ltd
 Cerpa, N. Verner, J. M (2009). Why Did Your Project Fail, Communications of the SCM. 52(12), 13-134.
 Dey, P.K. (2002). An integrated assessment model for cross-country pipelines, Environmental
Impact Review, Vol. 22(1). 703-21
 Boehm, B.W., (1991). Software risk management principles and practices. IEEE Software 8 (1), 32–41.
 Reh, F.J (2010). Pareto’s Principle – The 80-20 Rule. Retrieved March 08, 2010 from http://management.about.com/cs/generalmanagement/a/Pareto081202.htm
 Misra, S. C., Kumar, V. & Kumar U. (2006). Different Techniques for Risk Management in Software Engineering. 34th Annual Conference at Administrative Sciences Association of Canada (ASAC) June 3-6, 2006, Banff, Alberta, CANADA