30 Risk Management II

R. Baskaran

 

SOFTWARE RISK MANAGEMENT

 

Project risks are defined as the undesirable event, the chance that an event might occur and the consequences of all possible outcomes. Risk management attempts to identify such events, minimize their impact & provide a response if the event is detected.

 

LEARNING OBJECTIVES 

  • To identify potential software risks as required by the grading level.
  • To determine the Likelihood and consequences of the safety software failure.
  • To elaborate on risk management policies and process.
  • To establishment of risk thresholds for the safety software application.

 

RISK MANAGEMENT PARADIGM

 

The risk management includes the following:

  • Identify: Search for the risks before they create a major problem.
  • Analyze: Understand the nature, kind of risk and gather information about the risk.
  • Plan: Convert them into actions and implement them.
  • Track: We need to monitor the necessary actions.
  • Control: Correct the deviation and make any necessary amendments.
  • Communicate: Discuss about the emerging risks and the current risks and the plans to be undertaken.
  • Planning: Looking for the desired results, the strategies to be applied.
  • Organizing:  Getting all the things together so that the desired results are obtained. By organizing the efficiency is increased and lot of time is saved.
  • Directing: Communication takes place and exchange of ideas is formatted in this phase.
  • Controlling: In the last phase feedback and evaluation is done.

 

TEAM RISK MANAGEMENT PRINCIPLES

 

Team risk management involves two principles which are as follows:

  • Shared  Product  Vision:  The  common  goal  between  the  team  and  the  supplier  is established so that the vision is very lucid.
  • Team work: Working collectively towards achieving a common goal. The best way to snub the risks to some extent is to involve the customers’ right from the beginning and build a team oriented approach.

 

RISK MANAGEMENT IN SMALL PROJECT 

 

Risk Management in small projects comprises of preparing for risks which include external and internal risks such as uncertain requirements, unknown technology, infeasible design, and cost schedule uncertainty. The risks are identified and analyzed to understand the nature of risks and prioritize the risks and try to solve the risks. Mitigation of the risks is done which involves risk acceptance, risk transfer, risk avoidance and risk control.

 

Assessing the Risk Impact 

 

All risks need not be subject to monitoring and control. Scenario Analysis is used to assess the risk event impact. All consequences and their severity are determined if the event happen. When the event is likely to happen during the project is identified and the probability that the risk event will occur is estimated. The difficulty in detecting the event occurrence is determined.

Risk response strategies

 

Risk response strategies include the following:

  • Mitigating risk: Actions are taken during the project to either reduce the likelihood of a risk or reduce the impact of the risk. For example, testing electrical components after receipt would reduce the likelihood that “bad” parts would be used in a circuit.
  • Retaining risk: Risks are retained usually for events with low probability but high impact when no alternate strategy is feasible.  A contingency plan is kept ready, in case an event occurs.
  • Sharing risk: Multiple units associated with the project assume some portion of the risk.
  • Transferring risk: Risk is assumed and managed by a unit outside the immediate project.

 

For example, risks associated with the balloon vehicle are transferred to the project management.

 

Response development for risks 

 

A risk response plan identifies the primary components necessary for managing the risk and the response strategy that will be used is identified. Response development involves the understanding and detection of risk event so a response can be triggered. It involves in employing a plan in response to the event occurred and assigns who will be responsible for monitoring and controlling the risk. The response development for risk events, the contingency plan, the action triggered and the assignment of the responsibility is depicted in the following figure.

 

Contingency Planning

 

The risks associated with the technical aspects of a project can have the most severe outcomes. It can be mitigated by building and testing prototypes of critical components. The risks can be mitigated by having available backup or alternate designs that have much lower risk. The risks associated with costs usually result from estimate errors and omissions as time & cost are related and the trade-off schedule delays with lower cost. “Descope” options remove components of the project, but still allow the primary mission to proceed.

 

Risk Management 

 

The risks that occur in a project can be managed by employing the following steps:

  • Determine risk sources and their categories.
  • Determine risk parameters.
  • Establish a risk management strategy.
  • Identify risks.
  • Evaluate and prioritize the risks.
  • Develop and implement risk mitigation plans.

 

Risk Mitigation 

 

An effective strategy for dealing with risk must consider the following three issues (these are not mutually exclusive):

  • Risk mitigation (i.e., avoidance).
  • Risk monitoring.
  • Risk management and contingency planning.

 

Risk mitigation (avoidance) is the primary strategy and is achieved through a plan. Example: Risk of high staff turnover. The strategy for reducing staff turnover involves meeting with the current staff to determine causes for turnover (e.g., poor working conditions, low pay and competitive job market). Mitigate those causes that are under our control before the project starts. Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave. Project teams are organized so that information about each development  activity  is  widely  dispersed.  The  documentation  standards  are defined  and mechanisms are established to ensure that documents are developed in a timely manner. Peer reviews of all work are conducted so that more than one person is “up to speed”. The backup staff member for every critical technologist is assigned to avoid risks that arise due to the absence of the critical technologist.

 

During risk monitoring, the project manager monitors factors that may provide an indication of whether a risk is becoming more or less likely. Risk management and contingency planning assume that mitigation efforts have failed and that the risk has become a reality. RMMM steps incur additional project cost as large projects may have identified 30 – 40 risks. Risk is not limited to the software project itself but can occur after the software has been delivered to the user.

 

Software safety and hazard analysis 

 

These are software quality assurance activities that focus on the identification and assessment of potential hazards that may affect software negatively and cause an entire system to fail. If hazards can be identified early in the software process, software design features can be specified that will either eliminate or control potential hazards.

 

RMMM PLAN 

 

The RMMM plan may be a part of the software development plan or may be a separate document. Once RMMM has been documented and the project has begun, the risk mitigation, and monitoring steps begin. Risk mitigation is a problem avoidance activity and risk monitoring is a project tracking activity.

 

Risk monitoring has three objectives that include the assessment whether the predicted risks do, in fact, occur. It ensures that risk aversion steps defined for the risk are being properly applied and collects information that can be used for future risk analysis. The findings from risk monitoring may allow the project manager to ascertain what risks caused which problems throughout the project.

 

SEVEN PRINCIPLES OF RISK MANAGEMENT

  • Maintain a global perspective – It involves viewing software risks within the context a system and the business problem that is intended to solve.
  • Take a forward-looking view– Think about risks that may arise in the future and establish contingency plans.
  • Encourage open communications – Encourage all stakeholders and users to point out risks at any time.
  • Integrate risk management -Integrate the consideration of risk into the software process
  • Emphasize a continuous process of risk management – Modify identified risks which are known and add new risks so better insight is achieved
  • Develop a shared product vision – A shared vision by all stakeholders facilitates better risk identification and assessment.
  • Encourage teamwork when managing risk – Pool the skills and experience of all stakeholders when conducting risk management activities

 

RISK RESPONSE PROCESS CONTROL 

 

The Risk Management Plan should specify the risks, risk responses, and mechanisms used to control the process. Risks must be continuously monitored for risk triggers. Potential risk events should be identified early in a project and monitoring for such events immediately commence. Each risk is assigned to a specific person who has the expertise and authority to identify and provide a response to an event. Risk response process control needs an environment where problems are readily reported, embraced and solved. Changes in any aspect of the project need to be documented and communicated. The authority to approve a change must be assigned and the changes must be communicated to the team. Written forms are employed to track hardware, software and document changes. The members who are notified of changes, when the change is made and the change that is made must be documented.

 

Summary 

 

Whenever much is riding on a software project, common sense dictates risk analysis. Yet, most project managers do it informally and superficially, if at all. However, the time spent in risk management results in less upheaval during the project, provides a greater ability to track and control a project and incorporates confidence as plans for problems are devised before problems occur. Risk management can absorb a significant amount of the project planning effort, but the effort is worth it.

 

 

Web Links

  • https://www.theirm.org/the-risk-profession/risk-management.aspx
  • www.rmmagazine.com/
  • https://www.mcxindia.com/education-training/knowledge-series/risk-management

 

Supporting & Reference Materials

  • Roger S. Pressman, “Software Engineering: A Practitioner’s Approach”, Fifth Edition, McGraw Hill, 2001.
  • Pankaj Jalote, “An Integrated Approach to Software Engineering”, Second Edition, Springer Verlag, 1997.
  • Ian Sommerville, “Software Engineering”, Sixth Edition, Addison Wesley, 2000.