Sakshi Education
A common saying, a successful person is the one who takes the risks and finds a way to crack the risk.
The same applies for software development process too; successful software development involves management of greater risks and overcoming. A risk is a potential problem – it might happen and it might not. Conceptually speaking risk can be considered as: concerns future happenings, involves change in mind, opinion, actions, places, etc and involves choice and the uncertainty that choice entails. Two major characteristics of risk are: Uncertainty & Loss
Uncertainty – Here risk may or may not happen, this is an indecisive case.
Loss- This is a decisive case where risk is born to happen and consequences of the risk are also bared.
Reactive Risk Management
In this sort of risk management, the reactance to risk happens only when risk is encountered. That’s why this is called a fire fighting mode. When this fails, “crisis management” takes over and the project is in real jeopardy.
Proactive Risk Management
This technique operates on a principle of “prevention is better than cure”, where team starts forecasting in the initial stages of development, regarding the chances of the risks expected to come and starts working on the situations to avoid their existence. Potential risks are identified; their impact is assessed, and stroked as per magnitude. Then, the software team establishes a plan for avoiding and managing of risk.
Software Risks
Risk always involves two characteristics:
When risks are analyzed, it is important to quantify the level of uncertainty and the degree of loss associated with each risk.
To accomplish this, different categories or types of risks are considered.
Technical risks
Technical risks are targeted to affect the quality and time frame of the software production. If a technical risk becomes a reality, implementation may become difficult or impossible. Technical risks project issues pertaining to design, implementation, interface, verification, technology and maintenance.
Business Risk
Business risks affect the feasibility of the software to be built. Business risks often put in danger the project or the product. As referred by Roger pressmen, top five business risks are:
Known Risk
Known risks are those that can be uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed, other reliable information sources (e.g., unrealistic delivery date, lack of documented requirements or software scope, poor development environment). Predictable risks are generalized from past project experience. Unpredictable risks are the joker in the deck. They can and do occur, but they are extremely difficult to identify in advance.
Risk Identification
As stated by the Roger pressmen, Risk identification is a systematic attempt to specify threats to the project plan. This is the crucial step in project development, as this assists the team to forecast the risks and can work on preventive measures.
Two distinct types of risks
Generic risks are a potential threat to every software project
Product-specific risks can be identified only by those with a clear understanding of the technology, the people, and the environment that is specific to the project at hand.
To identify product-specific risks, the project Plan and the software statement of scope are examined. One method for identifying risks is to create a risk item checklist.
The checklist can be used for risk identification and focuses on some subset of known and predictable risks in the following generic subcategories:
Risk Item Checklist
Customer characteristics —risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner.
Process definition —risks associated with the degree to which the software process has been defined and is followed by the development organization.
Development environment —risks associated with the availability and quality of the tools to be used to build the product.
Technology to be built —risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system.
Staff size and experience —risks associated with the overall technical and project experience of the software engineers who will do the work.
Risk Components
PM identifies the risk drivers that affect software risk components:
Performance risk—the degree of uncertainty that the product will meet its requirements and be fit for its intended use.
Cost risk—the degree of uncertainty that the project budget will be maintained.
Support risk—the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance.
Schedule risk—the degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time.
The impact of each risk driver on the risk component
Risk Projection
Risk projection, also called risk estimation, attempts to rate each risk in two ways:
The project planner, along with other managers and technical staff, performs four risk projection activities:
The intent of these steps is to consider risks in a manner that leads to prioritization. By prioritizing risks, the team can allocate resources where they will have the most impact.
Developing Risk Table
Procedure to build risk table 
Assessing Risk Impact
Three factors affect the consequences that are likely if a risk does occur:
The nature of the risk indicates the problems that are likely if it occurs. For example, a technical risk, development environment change. The scope of a risk combines the strictness with its overall distribution. For ex. how much of the project will be affected or how many customers are harmed? The timing of a risk considers when and for how long the impact will be felt. Example- the software team defines a project risk in the following manner:
Risk Mitigation, Monitoring, and Management
Risk analysis assists in developing a strategy to deal risks. An effective strategy must consider three issues:
Proactive approach to risk, avoidance is always best than treating it after risk existence. This is achieved by developing a plan for risk mitigation. For example, assume that high staff turnover (i.e. revenue) is noted as a project t risk. To mitigate this risk, project management must develop a strategy for reducing turnover.
Steps are:
THE RMMM PLAN
The RMMM plan documents all work performed as part of risk analysis and is used by the project manager as part of the overall project plan. Some software teams do not develop a formal RMMM document. Rather, each risk is documented individually using a risk information sheet (RIS). RIS is maintained using a database system, so that creation and information entry, priority ordering, searches, and other analysis may be accomplished easily. Once RMMM has been documented and the project has begun, risk mitigation and monitoring steps commence.
Uncertainty – Here risk may or may not happen, this is an indecisive case.
Loss- This is a decisive case where risk is born to happen and consequences of the risk are also bared.
Reactive Risk Management
In this sort of risk management, the reactance to risk happens only when risk is encountered. That’s why this is called a fire fighting mode. When this fails, “crisis management” takes over and the project is in real jeopardy.
Proactive Risk Management
This technique operates on a principle of “prevention is better than cure”, where team starts forecasting in the initial stages of development, regarding the chances of the risks expected to come and starts working on the situations to avoid their existence. Potential risks are identified; their impact is assessed, and stroked as per magnitude. Then, the software team establishes a plan for avoiding and managing of risk.
Software Risks
Risk always involves two characteristics:
- Uncertainty —the risk may or may not happen; that is, there are no 100% probable risks.
- Loss—if the risk becomes a reality, unwanted consequences or losses will occur
When risks are analyzed, it is important to quantify the level of uncertainty and the degree of loss associated with each risk.
To accomplish this, different categories or types of risks are considered.
- Project Risks
- Technical Risks
- Business Risks
- Known Risks.
- Predictable Risks
- Unpredictable Risks
Technical risks
Technical risks are targeted to affect the quality and time frame of the software production. If a technical risk becomes a reality, implementation may become difficult or impossible. Technical risks project issues pertaining to design, implementation, interface, verification, technology and maintenance.
Business Risk
Business risks affect the feasibility of the software to be built. Business risks often put in danger the project or the product. As referred by Roger pressmen, top five business risks are:
- Building a excellent product or system that no one really wants (market risk),
- Building a product that no longer fits into the overall business strategy for the company (strategic risk)
- Building a product that the sales force doesn't understand how to sell.
- Losing the support of senior management due to a change in focus or a change in people (management risk)
- Losing budgetary or personnel commitment (budget risks)
Known Risk
Known risks are those that can be uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed, other reliable information sources (e.g., unrealistic delivery date, lack of documented requirements or software scope, poor development environment). Predictable risks are generalized from past project experience. Unpredictable risks are the joker in the deck. They can and do occur, but they are extremely difficult to identify in advance.
Risk Identification
As stated by the Roger pressmen, Risk identification is a systematic attempt to specify threats to the project plan. This is the crucial step in project development, as this assists the team to forecast the risks and can work on preventive measures.
Two distinct types of risks
Generic risks are a potential threat to every software project
Product-specific risks can be identified only by those with a clear understanding of the technology, the people, and the environment that is specific to the project at hand.
To identify product-specific risks, the project Plan and the software statement of scope are examined. One method for identifying risks is to create a risk item checklist.
The checklist can be used for risk identification and focuses on some subset of known and predictable risks in the following generic subcategories:
- Product size —risks associated with the overall size of the software to be built or modified.
- Business impact —risks associated with constraints imposed by management or the marketplace.
Risk Item Checklist
Customer characteristics —risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner.
Process definition —risks associated with the degree to which the software process has been defined and is followed by the development organization.
Development environment —risks associated with the availability and quality of the tools to be used to build the product.
Technology to be built —risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system.
Staff size and experience —risks associated with the overall technical and project experience of the software engineers who will do the work.
Risk Components
PM identifies the risk drivers that affect software risk components:
Performance risk—the degree of uncertainty that the product will meet its requirements and be fit for its intended use.
Cost risk—the degree of uncertainty that the project budget will be maintained.
Support risk—the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance.
Schedule risk—the degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time.
The impact of each risk driver on the risk component
Risk Projection
Risk projection, also called risk estimation, attempts to rate each risk in two ways:
- The likelihood or probability that the risk is real.
- The consequences (i.e. effect or result) of the problems associated with the risk, should it occur.
The project planner, along with other managers and technical staff, performs four risk projection activities:
- Establish a scale that reflects the supposed likelihood of a risk
- Describe the consequences of the risk,
- Estimate the impact of the risk on the project and the product,
- Note the overall accuracy of the risk projection so that there will be no misunderstanding
The intent of these steps is to consider risks in a manner that leads to prioritization. By prioritizing risks, the team can allocate resources where they will have the most impact.
Developing Risk Table
Procedure to build risk table
- Listing all risks in first column. This can be accomplished with the help of the risk item checklists
- Each risk is categorized in the second column
- The probability of occurrence of each risk is entered in the next column of the table, which can be estimated by team members.
- Impact of each risk is assessed. Each risk component is assessed using the characterization and impact categories like catastrophic, critical, marginal and negligible are determined.
- Once table is completed, manger will give order of prioritization to the risk. Therefore, the table is sorted by probability and by impact.
- Risk impact and probability have a distinct influence on management concern.
- Risk factor that has a high impact but a very low probability of occurrence then management will give little attention or some time no attention.
- But if risk factor that has high impact and high probability of occurrence then management will give high attention.
- All risks that lie above the cutoff line must be managed and specify in last column of the table under RMMM column.
Assessing Risk Impact
Three factors affect the consequences that are likely if a risk does occur:
- Nature,
- Scope, and
- Timing.
The nature of the risk indicates the problems that are likely if it occurs. For example, a technical risk, development environment change. The scope of a risk combines the strictness with its overall distribution. For ex. how much of the project will be affected or how many customers are harmed? The timing of a risk considers when and for how long the impact will be felt. Example- the software team defines a project risk in the following manner:
- Risk Identification - Only 70 percent of the software components scheduled for reuse and remaining functionality will have to be custom developed.
- Risk probability. 80% (likely).
- Risk Impact – Assume total no. of component is 60. If only 70 percent can be used, 18 components would have to be developed from scratch.
- Since the average component is 100 LOC and local data indicate that the software engineering cost for each LOC is $14.00,
- the overall cost (impact) to develop the components would be
- 18 x 100 x 14 = $25,200.
- Risk exposure. RE = 0.80 x 25,200 ~ $20,200.
- Once an estimate of the cost of the risk is derived, compute RE for each risk in risk table.
- The total risk exposure for all risks (above the cutoff in the risk table) can provide a means for adjusting the final cost estimate for a project.
- The project team should revisit the risk table at regular intervals, re-evaluating each risk to determine when new circumstances cause its probability and impact to change.
- As a consequence of this activity, it may be necessary to add new risks to the table, remove some risks that are no longer relevant, and change the relative positions of still others.
- Compare RE for all risks to the cost estimate for the project. If RE is greater than 50 percent of project cost, the feasibility of the project must be evaluated.
Risk Mitigation, Monitoring, and Management
Risk analysis assists in developing a strategy to deal risks. An effective strategy must consider three issues:
- Risk avoidance or mitigation.
- Risk monitoring
- Risk management and contingency planning
Proactive approach to risk, avoidance is always best than treating it after risk existence. This is achieved by developing a plan for risk mitigation. For example, assume that high staff turnover (i.e. revenue) is noted as a project t risk. To mitigate this risk, project management must develop a strategy for reducing turnover.
Steps are:
- Meet with current staff to determine causes for turnover (e.g., low pay, competitive job market).
- Lessen those causes that are under our control before the project starts.
- Organize project teams so that information about each development activity is widely dispersed.
- Define documentation standards and establish mechanisms to be sure that documents are developed in a timely manner.
- Conduct peer reviews of all work
- Assign a backup staff member for every critical technologist.
- As the project proceeds, risk monitoring activities commence.
- The project manager monitors factors that may provide an indication of whether the risk is becoming more or less likely.
- In the case of high staff turnover, the following factors can be monitored:
- General attitude of team members based on project pressures.
- Potential problems with compensation and benefits.
- The availability of jobs within the company and outside it.
- Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become a reality.
- The project is well underway and a number of people announce that they will be leaving. If the mitigation strategy has been followed, backup is available, information is documented, and knowledge has been dispersed across the team.
- In addition, the project manager may temporarily refocus resources (and readjust the project schedule) to those functions that are fully staffed, enabling newcomers who must be added to the team to “get up to speed.”
- Those individuals who are leaving are asked to stop all work and spend their last weeks in “knowledge transfer mode.”
- This might include video-based knowledge capture, the development of “commentary documents,” and/or meeting with other team members who will remain on the project.
- RMMM steps incur additional project cost. For example, spending the time to "backup" every critical technologist costs money.
THE RMMM PLAN
The RMMM plan documents all work performed as part of risk analysis and is used by the project manager as part of the overall project plan. Some software teams do not develop a formal RMMM document. Rather, each risk is documented individually using a risk information sheet (RIS). RIS is maintained using a database system, so that creation and information entry, priority ordering, searches, and other analysis may be accomplished easily. Once RMMM has been documented and the project has begun, risk mitigation and monitoring steps commence.
Published date : 10 Apr 2015 05:32PM
