ABSTRACT

The comprehensive risk management system based on the software project features of H Corp. is established, the causal relationships among risk factors are discovered, and corresponding risk structure model is built with ISM. Five original risk factors are found, including requirements analysis risk, project communication risk, schedule risk, risk of system design, and risk of project cooperation. Finally, some specific counter measures are put forward to help H Corp. improve the ability of software project risk management.

1. Introduction

Today, financial innovation has become the core competitiveness of small and medium-sized financial institutions, financial tools built with the information technology have made more complex financial products transactions become reality. However, the financial industry highly depends on information technology, which makes the safety, reliability and efficiency of information technology system directly affect the entire banking industry security and the stability of the financial system. Since 2010, supervision departments have paid high attention to risk management of IT (information technology). A series of guidelines and regulatory documents have been launched. And in 2011 Senior Banking Information Technology Risk Management Steering Committee has been founded, guided by Total Risk Management, to promote the continuous, healthy development of information technology of the financial industry.

Auto Finance Ltd. is not a banking finance organization, but provides professional financial services for car dealers and terminal customers, so its loan portfolios are increasing. In order to support this trend, a mount of information systems are establishing, and more effective cooperation are needed among systems and projects, which make a severe stress to the instruction and operation of IT system. And in this process if the capacity of management and control can’t keep up, it will lower the quality of software products and cause system operating risks. In this paper, we will construct a risk structure model for H Corp. and then find out some original risks to propose several solutions. The contents are as follows: Section 2 is literature review, Section 3 is H Corp. software project risk management analysis, Section 4 is to construct a software project risks structure model with ISM, Section 5 is the analysis and counter measures for the key risk of H Corp. software project, and session six is conclusions.

2. Literature Review

The software risk management involves two primary steps each with three subsidiary steps is illustrated in Figure 1 [1].

The first primary step, risk assessment, involves risk identification, risk analysis, and risk prioritization: 1) Risk identification produces lists of the project-specific risk items likely to compromise a project’s success. Typical risk identification techniques include checklists, examination of decision drivers, comparison with experience (assumption analysis), and decomposition; 2) Risk analysis assesses the loss probability and loss magnitude for each identified risk item, and it assesses compound risks in risk item interactions. Typical techniques include performance models, cost models, network analysis, statistical decision analysis, and quality-factor (like reliability,

availability, and security) analysis; 3) Risk prioritization produces a ranked ordering of the risk items identified and analyzed. Typical techniques include risk-exposure analysis, risk-reduction leverage analysis (particularly involving cost-benefit analysis), and Delphi or group-consensus techniques.

The second primary step, risk control, involves riskmanagement planning, risk resolution, and risk monitoring: 1) Risk-management planning helps prepare you to address each risk item (for example, via information buying, risk avoidance, risk transfer, or risk reduction), including the coordination of the individual risk-item plans with each other and with the overall project plan. Typical techniques include checklists of risk-resolution techniques, cost benefit analysis, and standard risk management plan outlines, forms, and elements; 2) Risk resolution produces a situation in which the risk items are eliminated or otherwise resolved (for example, risk avoidance via relaxation of requirements). Typical techniques include prototypes, simulations, benchmarks, mission analyses, keypersonnel agreements, design-to-cost approaches, and incremental development; 3) Risk monitoring involves tracking the project’s progress toward resolving its risk items and taking corrective action where appropriate. Typical techniques include milestone tracking and a top-10 risk-item list that is highlighted at each weekly, monthly, or milestone project review and followed up appropriately with reassessment of the risk item or corrective action.

J. P. Wan, D. Wan, and H. Zhang identified the risks of CN Group which is working at software outsourcing projects between Hong Kong and Guangdong, discovers the causal relationships among the risk factors, and constructs corresponding risk structure model with Interpretive Structural Modeling. Five original risk factors are identified, including contracts risk, requirements definition and change, lack of communication, political and legal environment differences, and exchange rate fluctuations [2]. J. P. Wan and D. J. Wan figured out eleven kinds of common mindbugs are figured out among the twenty five kinds of mindbugs with questionnaire. The relationship between the six root risk factors of implementation of the information technology service management (ITSM) project and these common mindbugs are also identified [3]. J. P. Wan and L. Y. Liang selected five common killer assumptions from Warfield’s 17 Killer assumptions through empirical analysis. Enterprise interview and questionnaire survey are used to establish and verify the relational model between the root risk factors of implementation of the ITSM project and the six complexity propositions based grounded theory [4]. J. P. Wan and J. J. Hou studied the possible risk factors during SAP Business One implementation with depth interview. The results were then adjusted by experts. 20 categories of risk factors that are totally 49 factors were found. Based on the risk factors during the SAP Business One implementation, questionnaire was used to study the key risk factors of SAP Business One implementation. The study illustrated that the structure is olive-like, in which the risk of data import is on the top, and the risk of senior managers is on the bottom [5].

3. H Corp. Software Project Risk Management Analysis

3.1. The Overview of H Corp. and Its Software Project

H Corp. is the first Auto Finance Ltd. in Guangdong province, providing auto financing services for car dealers and terminal customers of its parent company’s related brands. Its core business platforms consist of automotive retail credit business system (NETSOL), approval system for inventory business, capital management system, general ledger system, and the data warehouse platform. All the other systems are referred to as peripheral systems. In the process of the project, core business systems are in the center, peripheral systems can communicate with the cores directly, or via the agency. Strict message rules, definite handshakes and rigorous enciphered message should be established for smooth communication.

There are several features of H Corp. software projects. 1) Both core business systems and peripheral systems are closely related to the business and its process; 2) The specifications are very strict in many aspects, including project, document, process, design, development, code, test, end of the project, etc. We should comply with the specifications strictly; 3) All the projects are affiliated to the IT department, but the requirements are put forward by the related business departments; 4) It’s only cooperation with each other that we can success; 5) The fruits of the project are not only the project itself, but also something abiding the specifications, including SC (source code), design document, prototypes, operation manual, and inspection report, etc.

3.2. Analysis of Comprehensive Risk Management System

A comprehensive risk management system is established for the success of H Corp. Software project (Figure 2). The contents are as follow. 1) The environment of risk management can be divided into the internal and the external. Including the culture of risk management, the project management policy, matrix organization structure, etc.; 2) The policy of risk management is to define the process and content of the risk management, formulate

the report template for the regular work; 3) We will make a detailed instruction about the process of risk identification in the part 4; 4) Risk evaluation contains qualitative analysis and quantitative analysis, is to make sure the effect and loss extent of the risk accidents; 5) After the identification and evaluation of the risk, we can make specific counter measures to response the risk; 6) A internal control system should be established by internal control department and continuous control department to discover the problem, propose the improvement plan and put it into effect; 7) Recognize, judge, analyze and evaluate the risk source, then dispose and make a report. This process will provide basis for the next risk coming; 8) The constant improvement of risk management can be based on Kaizen Process-PDCA.

3.3. The Construction of Comprehensive Risk Management System

We can construct the comprehensive risk management system of H Corp. software project in three aspects. Firstly, on the aspect of organizational structure, we should make sure that board of directors, executive and Communication and Information Technology Commission (CITC) will be responsible for IT risk strategy, and resource allocation. The orientation of IT risk management institutions should be defined. The IT risk management responsibility of every department should be clear. Three lines of defence has been established as follow (Figure 3), and IT management department, risk management department, each business line in the front, each support department in the background, institutions at all levels should be fully participated. Second, on the policy aspect, IT risk should belong to company risk management policy. Last, on the process aspect, IT management department should report to department head and Chief Risk Officer discretely, analyze the IT cases regularly, complete the policy, and promote the improvement of management process and solution of the problem.

3.4. Software Project Risk Control Strategy

In view of comprehensive risk management system, the risk management of the software project has the following steps: 1) Build enterprise risk management culture, make more training and communication to improve the internal risk management environment; 2) Set clear risk management objectives and policies; 3) Establish a perfect risk identification and monitoring system; 4) improve the skill of risk evaluation continuously; 5) Perfect risk counter measures step by step, and establish risk database in order to prevent the risk advance; 6) Establish a perfect internal control system led by the continuous control department; 7) Set up a risk disclosure and reporting system; 8) Establish the continuous improvement system of risk management.

4. Construct a Software Project Risks Structure Model with ISM

4.1. Identify the Risks of the Software Project

The major event sequence of ISM is in the following [6]: 1) Theme is selected; 2) Developer is identified; 3) Elements and contextual relation are identified; 4) Leader is identified; 5) ISM program is entered in computer; 6) Adequate computer time is allocated; 7) Facilities are

ready; 8) Session plan is complete; 9) Computer contains elements and contextual relation; 10) Session can begin; 11) Element set is edited; 12) Reachable matrix is complete; 13) Total structure is available; 14) Amendments are complete; 15) Final structure is satisfactory.

According to the ten risk categories of financial services proposed by the Basel Committee on Banking Supervision, we deeply analysis the risk we met in the process of the project from aspects, such as the risk types, risk description, risk probability, risk incidence, processing mode, etc. Then 20 major risk factors of IT projects of H Corp. were found out. These risks can be illustrated in Table 1.

We consult with experts, who come from company internal risk management team or project team with Delphi, including Project managers, Developers, Testers, Business personnel, Software development and the internal control manager, QA, etc. By the way of calculating variable coefficient, we analysis the opinions of the experts, then conclude the descriptive statistics risks of software project, which can be illustrated in Table 2.

4.2. Construct Adjacency Matrix and Reachable Matrix

Construct an adjacency matrix according to risk factors and its weight. It is illustrated in Figure 4.

Calculate by ISM Win 1.1, we can get a reachable matrix. It is illustrated in Figure 5.

4.3. Construct the Re-Order Reachable Matrix M’

According to the result of class division, we can get the re-order reachable matrix as follows (Figure 6).

4.4. Construct the Interpretive Structural Model

According to the re-order reachable matrix, we can construct the risk structural model of H Corp. They can be illustrated by Figure 7.

4.5. Analyze the Interpretive Structural Model

After the analysis, we discover the software project risk factors of H Corp. in four level structures (Figure 8). It can be seen from Figure 7 that this model is a directed four-level hierarchical structure model, and that the bottom-line arrows indicate low-level factors affecting highlevel factors. By replacing risk factors code with the actual risk factors, the interpretative structure model of H’s software project risk is established.

1) The lowest level constitute of human resource risk, supplier selection blunders, and communication risk. They are the key factors affecting the success of software projects; especially, the risk of supplier selection blunders occur in the early stages of operation of software projects, having significant impact on the process of cooperation and success of H Corp.’s project. So it deserves much more attention.

2) The factors of the second layer is the direct risk factors resulting H Corp. to crisis, including time risk, losing control of milestones, and the risk of requirement change. Three risks are indirectly affected by a variety of risk factors.

3) Uncertain demand analysis, design deviation, the lack of client support and outsourcing decision-making failure is the direct reason, which leads to the project schedule risk, losing control of milestones, demand change. The direct reasons should be monitored in the process of software project.

4) Time risk mainly due to design deviation, the lack of client support, outsourcing decision-making risk, inaccurate requirement. The deeper reasons are lacking of effective communication, the mistakes in selection of suppliers is caused by lacking comprehensive assessment of suppliers’ technical human resource and management level results, the team human resource changing, and technological level & professional skill falling behind.

5. The Counter Measures for the Risk Management of H Corp. Software Project

According to the ISM model above, we discover five critical risks of H Corp. software project, which constitute of requirements analysis risk, project communication risk, schedule risk, risk of system design, and risk of project cooperation. Now we will analysis the critical risks and try to put forward some specific counter measures.

5.1. Requirements Analysis Risk

There are three typical requirements analysis risks in the process of software project, critical users can’t participate in the process of requirements analysis, so the team can’t accurately grasp the user’s real requirements; with the micro-increasing of the project functions and features, the requirements of the project is extending; and the business requirements jump when the project functions and features are changing obviously. Facing these risks, we can apply the measures as follows. 1) control the requirements change by specifying the process, defining the criteria, confirming the priority rating, or guiding the change by communicating; 2) control the requirement quality by specifically investigating the critical users; 3) control the requirements understanding deviation caused by the differences between business personnel and technical personnel in the professional background and job field by communicating sufficiently or confirming repeatedly.

5.2. Project Communication Risk

Lack of communication, the business personnel, IT developers and the technical team of outsourcers would not take fully advantage of cooperation. In order to communicate in time, we can do as follows: 1) formulate a detailed project communication plan; 2) keep in touch closely with project stakeholders by various channels of communication; 3) hold the project team meeting regularly; 4) questionnaire survey first to make project requirements and difficulties clear in the requirements analysis phase of the project. 5) because of the special personality of the financial system project, there is no general development mode in the industry, so the support should be timely provided by the business analysts.

5.3. Project Schedule Risk

Project delay not only makes members under high pressure, but also leads to the dissatisfaction of the stakeholders. The counter measures are in the following. 1) establish a communication system and the technical personnel should be trained heavily to improve the ability for handling problems; 2) define the project process to make sure the project-related personnel can finish their own job on time; 3) make sure all the team members know all the project requirements; 4) formulate the project emergency plan; 5) show the project fruit in time in the process to motivate the team members.

5.4. Risk of System Design

The risk of system design mainly includes integrity risk, risk of data storage, data acquisition risk and risk of architecture, etc. The counter measures are in the following. 1) establish review committee and change management system; 2) define the criteria of connector to the different Apps; 3) according to the method of system engineering and certain criteria, combining with the principle of management information system, under the condition of the stable system structure frame, develop business systems step by step. An integrated planning of the system and certain technical criteria should be defined by IT department. By doing these, we could make sure the success of the present project, the stability of data changing among the systems, and reduce the risk of project failure. So the construction of the IT system is under the control.

5.5. Risk of Project Cooperation

The risks of project cooperation not only refer to the risk inside the project team and between different departments, but also contain all the risks between company and outsourcers in the process. In order to avoid these risks, we can follow the counter measures. 1) Project managers should pay more attention to the leadership and management; 2) when it comes to the part outsourcing of the project, we should fully consider the feasibility and cost, and rigorously evaluate the outsourcers, including technology, management level, corporate organizational structure, industry experience, and after-sale service, etc.; 3) Team members should keep good touch with each other and learn to communicate with the supplier forwardly; 4) A training to technical personnel of outsourcers should be conduct by IT department in accordance with the continuous control institution of the company; 5) When the project environment changing, IT department should evaluate its effect to the service of the outsourcers, and put forward the related plan to make sure the success of the project; 6) In the process of system development, we could apply related counter measures to ensure information security management fit the institution of the company; 7) After system launched and operated normally, IT department should found a effective communication system with the outsourcers, so as to acquire technical support in time.

6. Conclusion

The comprehensive risk management system based on the software project features of H Corp. is established, the causal relationships among risk factors are found, and corresponding risk structure model is built with ISM. Five original risk factors are found, including requirements analysis risk, project communication risk, schedule risk, risk of system design, and risk of project cooperation. Finally, some specific counter measures are put forward to help H Corp. improve the ability of software project risk management.

7. Acknowledgements

Thanks for helpful discussion with Mr. Jinghe Wang, et al.

REFERENCES

NOTES

^*This research was supported by Key Project of Guangdong Province Education Office (06JDXM63002), NSF of China (70471091), and QualiPSo (IST-FP6-IP-034763).