1. Introduction

Software risk management process is different from the other products risk management due to the non-physical nature of deliverables. There have been proposed a verity of methods for software projects risk management. Some of these methods identify, monitor, and control the risks in accordance to the software development process, however, the rest of risk management methods act independently of the development process and do the risk management process by focusing on risks classification and risk factors identification[1]. An important point that researchers are emphasizing on is that risks have a changing nature. This means that a lot of internal or external, controllable or uncontrollable, hidden or obvious factors are affecting risk factors frequently, continuously, and dynamically[2].

By considering the aforementioned issues, this research proposes an iterative model with a dynamic verifier core to improve the risk management process by using some advantages of current models. To check the validity of the model, the risks of developing a Customer Relationship Management project are managed.

2. Dynamic Verifier Core (DVC)

Figure 1. The DVC steps

All the actions done for risk identifying and restraining are faced internally with some dangers, threats, and risks. Ignoring some risks, considering those risks that never happen, low or high unstable evaluations of risk factors probability occurrence, and their damaging impacts are some of the mentioned threats. When risk control process is properly performed during a project, the involved personnel do their responsibilities safely[3]. Therefore, weak risk management may amplify the threats of the project[4]. Embedding DVC in the centre of IT projects risk management is a beneficial approach to reduce the intensity of possible dangers and prevent probable deviations. There are three suggested steps for DVC as illustrated in figure 1.

At the end of each level in risk process, without considering the used method, the prepared reports, calculations, and documents deliver to DVC core, to audit and identify probable deviations from the goals, programs, and actions. Finally the required actions for removing such errors will be applied.

2.1. Risk Review Committee Combination

The risk management process is a professional job throughout which some experts with various skills and in different phases have special duties[5]. The main reason that most of risk management models are being done in some levels and phases, is that special experts do their professional activities in each phase.

Figure 2. The structure of the DVC for software analysis and assessment phases

Figure 3. The structure of the DVC for risk mitigation phase

By considering the aforementioned issues, at the end of each phase of risk process like risk identification, measurement, assessment, and mitigation, the related experts should be the review committee key members. Involving independent experts who are neither the direct stakeholders of this project, nor have personal interest or prejudice in this projects activities is recommended. Although, this committee can make decisions, it is suggested that project manager and risk manager have permanent plenipotentiary representatives in the committee. The last advice is that the number of committee members should be odd to avoid getting into deadlocks in decision making process and voting. Figures 2 and 3 show the structure of DVC for different phases of software risk management. The word “Dynamic” in the core indicates the flexibility of the structure of the committee. Figure 2 includes risk identification, risk measurement and risk assessment phases of software risk management. These three steps are called analysis and assessment phases. While figure 3 presents risk mitigation and contingency plan phase (See Fig. 2 & 3).

2.2. Identification and Classification of Deviations

As illustrated in figure 4, focusing on the goals of each step is the initial step to identify and classify the deviations[6]. Figure 4 illustrates DVC phases to control and mitigate arisen risks. By considering the changeability, flexibility, dynamism and risks reformation nature, the review committee should independently, accurately and fairly monitor the documents and activities and must be aware of project’s current status, threats and opportunities[7]. Therefore, using an interactive multi-user system called “Unseen-Overseen Project Change” (UOPC) to assist review committee is suggested.

Figure 4. The DVC phases

UOPC creates a link between project stakeholders, involved personnel, and even experts who were cooperating in the previous phases of risk process. While these people are facing to deliberate or unintentional changes, and even recognizing a threat or an opportunity, should broadcast their ideas, notices, and suggestions with the corresponding documents through the communication system to the review committee. Therefore, deviations’ classification could be predictable as below:

• Risk management actions’ deviations from the goal of each phase

• Risk management actions’ internal deviations in each phase

• Deviations from current requirements and real properties of the project compared to the initial requirements defined for risk management.

2.3. Recognizing the Severity of Deviations

Another important classification that should be done in DVC is to recognize the severity rate of the deviations. Three categories of deviation importance rate are: ignorable, resolvable in DVC, and necessary to be resolved by the originator. Classes two and three are ranked in a Meta class named “significant deviations.” Before the complete handling and removing the significant deviations, the rest of risk actions cannot be performed unless may lead to more deviations[8].

3. Customized Risk Factors

Table 1. The customized risk factors checklist

IT risk management scholars have proposed some different classifications for risk factors. Boehm is one of the earliest and effective experts in this field, who identified and proposed ten important risk factors from operational, practical, resources, and scheduling aspects[9]. Also in 2007, Symantec Corporation introduced four classes including security, availability, performance, and compliance with their sources and consequences. In 2008, Sutton and others have presented some risk factors from the aspects of system-user correlations, goals, and managers’ commitments in business systems[10].

The combinations of the studies done by the aforementioned researchers, OZ in 2000[11], Fairiey in 2003 [12], Tesch in 2007[13], and Fowler in 2007[14], are shown in Table 1. A comprehensive checklist of risk factors are gathered and presented in the following table which facilitates the risk management of IT projects.

4. The Case Study: Applying DVC on CRM Project

The selected company for the implementation of the model is working on some fields like interior and exterior design, industrial design, graphics, and multimedia. Customer Relationship Management (CRM) project is the current software system developing by this company. This project is the integration of various systems such as buy and sell, marketing and so on. The identified risks of this project are inserted in Table 2.

The remarkable point is that some risk factors can be in more than two classes. For instance, the risks arisen of using a new technology may relate concurrently to user capabilities, training programs, and attributes of the proposed technology.

Table 2. The identified risks during RM phases

5. Discussion and Results

The core of dynamic verifier was formed by creating a committee consists of company manager, financial manager, and projects administrator as the independent member. Deviations of the identified risks are explained in Tables 3 and 4.

Not only some important risks such as invoices confidentiality, data input control and protection risks were ignored, but also credit and contract risks were not identified either. There are some important points about DVC corrections; firstly, the main duty of DVC is to identify the unseen or newly arisen risks during the management process and prioritize the received risk factors and classifications based on their severity and occurrence. Secondly, as it is clear in Table 4, the Marginal risks will be ignored in DVC activities and the main focus and rankings id referred to Catastrophic and Critical risks.

Table 3. The new identified risks by DVC

Table 4. The verified risks by DVC

Another Specific feature of DVC is the flexible formation of expert committee. The combination of committee established for identifying deviations shows its high performance by addressing the weakness of software projects in contracts and costumer validation issues[15]. Thus, both software project and its product, that is, CRM system were improved. Adding related subsystems to the contracts as an important momentary requirement and defining subsystems for costumer identification, convert project hidden threats to opportunity. This opportunity is qualitative improvement of current processes and projects.

6. Conclusions

Re-monitoring the performed actions and prepared documents of every phase in the risk management, without considering the used approach, improves the efficiency of the model[16]. The proposed model in this research is to identify deviations and removing them, by forming experts committee who have various skills in related phases. Creating a dynamic communication link between project and organization employees and DVC practitioners facilitates the management of new or changed risks. This link also accelerates the identification and classification of the deviations. The case study shows the possibility of converting risks to opportunities by focusing on the project and IT product.