The History Of Risk Management Process

Published Date: 02 Nov 2017

ABSTRACT:

Developing software is really a high complex whether it’s done under a number of team or under an individual and so there are many risk associated with the complexity in it. And controlling the risks in software project is considered to be a major success of a software project. In this paper we will discuss about why we need risk management? Is it important for any software developing organization to have risk management? Moreover there are number of resources used in developing a project so is there any risk in using resources? And what is risk?

INTRODUCTION:

While developing software on time and within budget there can be many risks. Risk in software can be occurring in multiple types. Inaccurate estimating and schedule planning can be the cause of risk in software. Optimistic status report can also be the cause of risk. Risk can be from the eternal pressure, which damage software project. In order to take these risks, they must be compensated for by a perceived reward. The greater the risk the greater the reward must be to make it. There is potential of disaster because in software development possibility of risk is high. Software project can be managed successfully if we learn how to analyze, identify and control these risks. Where as many software developers and project managers perceive risk management process and activities as extra work and expense. The first thing that should be removed from project activities when the project slips is risk management processes.

Within risk management the "emphasis is shifted from crisis management to anticipatory management". There are four causes describes by Boehm to implement software risk management so that we can avoid software project destruction, failure in operations and budget and schedule run away.

Avoiding rework caused by erroneous, missing, or ambiguous requirements, design or code, which typically consumes 40-50% of the total cost of software development.

Avoiding overkill with detection and prevention techniques in areas of minimal or no risk. Stimulating a win-win software solution where the customer receives the product they need and the vendor makes the profits they expect.

DEFIINING RISK:

When completing a software project, there may be different types of risks that may occur. Software risks may be defined as the probability and relentlessness of adverse effects. The need to manage risk increases with time. Focus should be on cost overruns and schedule rather than on the root causes of the product acquisition and development. All areas in system development are suspected for risks including technology, hardware, software, cost, schedule and people. So, Software risks can be mainly divided into technical, management, financial, legal, resource risks and personnel risks. Technical risks includes risk regarding technical faults like inexperience programmers, problems with latest platforms , programming languages, project size , poorly defined parameters, etc. Management risks include risks that are related to no proper training, no resource planning, and no communication in team. Financial Risks includes risks regarding cash flow, budget, etc. they are cause because of wrong budget estimation, cost overruns and project scope expansion. Legal risks are included due to government regulation, product warranty issues, etc. Resource risks are caused due to late supply of resources, some issues in provided resources, new requirement of resources or due to lack of resources. Personnel risks are caused due to lack of training, staff conflicts, inexperience staff, etc.

RISK MANAGEMENT PROCESS:

Risk management process is the process that includes indentifying risks, analyzing risks, planning for risks, tracking those risks and controlling the risks. At first in risk management, all the risks are identified and prioritized and then planning for risks are done. The appropriate actions are taken to reduce the probability of risks if it occurs or reducing it if it turns into a problem. Some contingency actions are taken if turns into a problem. Then tracking of those risks are done. Tracking involves the monitoring of status of the risks. Then risk control relies on project management processes to control risk action plans, correct for variations from plans and improves identified risks. The whole risk management process is continued until all the actions regarding risks are taken.

RISK IDENTITFICATION:

First of all, all the risks are identified that may occur in the software project. These risks can be of any type technical or nontechnical. The risks are identified before it becomes a big problem and adversely affects the project. Some techniques are conducted to indentify the risks. It may include interviewing or brainstorming, voluntary reporting, assumption analysis, critical path analysis, risk taxonomies and decomposition. By meeting customers, team members and marketing representatives about the functionality or process of the project risks can also be identified. Risks can also be identified by reporting like reporting status. The team member who identifies risks rewarding for identifying risks. The person who identifies risk is aided by taxonomies or checklist. These checklists are also based on the past projects. Before doing critical path analysis all the risks should be identified to complete project on time. All the assumptions must be analyzed because if they are wrong then they can become a problem for completing and doing the project on time and on proper cost. By decomposing development process into further small parts some more risks can be identified and risk can easily be identified and controlled. If Unmanageable risks are further decomposed then they easily handled.

RISK ANALYSIS:

Each risk is assessed and prioritize in the risk analysis phase. The risks are assessed that they may occur that is the probability of risk to occur. Some risks are more likely to occur and others are less likely to occur. Then what will be the impact of the risk on the project will be identified. Impact can be on cost or schedule. Then it is also assessed that in which time the risk may occur that is the timeframe of the risk to occur. It is also identified that one risk is dependent on other risk or not. In Risk Analysis, each risk is considered and a judgment about the risk is made what should be done if the risk occurs. This phase can be considered as the decision making phase.

After the risk is assessed in the risk management process, the risks are prioritized. Risks should be prioritize to take actions for those risks that have high impact on the project and for those risks that have more likelihood to occur. It is very difficult to take actions for each identified risk. It is almost impossible to take action for each risk assessed because it may be time consuming and requires more cost. For prioritizing risks and assessing all the risks, Boehm explains an equation for risk exposure. Boehm defines Risk Exposure as probability of undesired outcome times the loss of the outcome [1]. Risk Exposure measures risk in terms of loss.

Risk Exposure (RE) = P * L

where P is the probability of the occurrence of the risk and L is the impact or loss occur by the risk.

RISK MANAGEMENT PLAN:

Risk management plan should be done so that appropriate actions can be taken. The reason to do a risk management planning is to know the consequences of the actions taken in the future for the risks that may create a problem for the project. Risk plans may information buying means requirement of more information to take actions regarding risks. Some plans should also make to reduce risk. Reduction risk involves that do some planning to reduce risks of the potential problems. E.g. if the team member knows that changing to new platform is risky for the project because it may take more time to team to understand it and team may slip from the critical path analyzed and project may not complete on time by changing the platform.

Sometimes team has to live the risk that may occur. They should consider the acceptance risk. These risks can be accepted and considered by the organizations because organizations can cope up with these risks. For acceptance risks no actions are taken. Contingency plans should be considered if risks are not eliminated. A contingency plans explains what should be done if the risk will become a problem. Contingency plans also include disaster recovery plan, alternative design approach. All the risks that are endangered for becoming a problem may also have trigger to occur. Trigger is the event or the time at which the risk occurs to start. Some risks low priority may also become of high priority in the future.

Boehm defined risk reduction leverage equation. Team should do accost or benefit analysis so that it can be identified that by implementing the actions for the plans made in the risk planning phase requires more cost than the cost occurs by the risks. Boehm explains Risk Reduction Leverage as the risk reduction before exposure minus risk reduction after exposure divided by cost of risk reduction [1].

Risk Reduction Leverage = (Risk reduction before exposure – risk reduction after exposure)/ cost of the risk reduction.

MONITOR/ ACTIONS:

All the risks are first identified, analyzed and assessed, planning is done and then actions are taken for the risks occurring in the project. Actions regarding all the risks should be taken that are planned earlier. Some additional actions are also taken if the risks can be reducing by the actions. All the tasks are assigned to team member to implement them. Some tasks are done earlier than the scheduled time and some tasks are performed later. Cost Estimation should also be done for these tasks so that these risks may not overrun the estimated budget.

TRACKING:

Tracking must be done for the implementation done for the risk reduction. Tracking may includes addition of new in the risk lists, remove risks from the list whose implementation is done, implementation of contingency plan. Tracking measures the risks that are known and the trigger occur by the risks. Some software

metrics can be taken to manage the project like Pert chart, Gantt chart, etc.

All the risks should be monitored at regular interval because some risks that are at high prioritization level may become at low prioritization level. Risks must be monitor regularly because as time gone on and project become more and more complex it may also be possible to refine the risk into detailed risks to easily monitor and mitigate it.

CONCLUSIONS:

As the software project’s complexity increases, it is also become important to implement risk management process for a successful project that is delivered on time. In appropriate attention to risk may give rise to more risks. Real changes will occur if project manager incorporates risk management. So, all the stake holders must communicate throughout the project for risk management. In the risk management process risks are identified, analyzed, planned, actions for those plans were done and then tracking was done. Risk Management is also included in PMBOK (Project Management Body Of Knowledge) standards set by PMI(Project Management Institute) where it is divide into risk identification, qualitative risk analysis, quantitative risk analysis, risk repose planning, risk management planning and risk monitoring and controlling. It is the job of the project manager to give bonuses to team members on the successful completion of the project.