What are the Risk management activities for a software project?
Risk are future uncertain events with a probability of occurrence and a potential for loss”. Risk identification and management are the main concerns in every software project. Effective analysis of software risks will help to effective planning and assignments of work. Risks are identified, classified and managed before actual execution of program. These risks are classified in different categories.
Risk management should:
• create value
• be an integral part of organizational processes
• be part of decision making
• explicitly address uncertainty
• be systematic and structured
• be based on the best available information
• be tailored
• take into account human factors
• be transparent and inclusive
• be dynamic, iterative and responsive to change
• be capable of continual improvement and enhancement
Categories of risks:
Schedule Risk:
Project schedule get slip when project tasks and schedule release risks are not addressed properly.
Schedule risks mainly affect on project and finally on company economy and may lead to project failure.
Schedules often slip due to following reasons:
• Wrong time estimation
• Resources are not tracked properly. All resources like staff, systems, skills of individuals etc.
• Failure to identify complex functionalities and time required to develop those functionalities.
• Unexpected project scope expansions.
Budget Risk:• Wrong budget estimation.
• Cost overruns
• Project scope expansion
Operational Risks:
Risks of loss due to improper process implementation, failed system or some external events risks.
Causes of Operational risks:• Failure to address priority conflicts
• Failure to resolve the responsibilities
• Insufficient resources
• No proper subject training
• No resource planning
• No communication in team.
Technical risks:
Technical risks generally leads to failure of functionality and performance.
Causes of technical risks are:
• Continuous changing requirements
• No advanced technology available or the existing technology is in initial stages.
• Product is complex to implement.
• Difficult project modules integration.
Programmatic Risks:
These are the external risks beyond the operational limits. These are all uncertain risks are outside the control of the program.
These external events can be:
• Running out of fund.
• Market development
• Changing customer product strategy and priority
• Government rule changes
Identification
After establishing the context, the next step in the process of managing risk is to identify potential risks. Risks are about events that, when triggered, cause problems. Hence, risk identification can start with the source of problems, or with the problem itself.
• Source analysis] Risk sources may be internal or external to the system that is the target of risk management.
Examples of risk sources are: stakeholders of a project, employees of a company or the weather over an airport.
• Problem analysis Risks are related to identified threats. For example: the threat of losing money, the threat of abuse of privacy information or the threat of accidents and casualties. The threats may exist with various entities, most important with shareholders, customers and legislative bodies such as the government.
When either source or problem is known, the events that a source may trigger or the events that can lead to a problem can be investigated. For example: stakeholders withdrawing during a project may endanger funding of the project; privacy information may be stolen by employees even within a closed network; lightning striking a Boeing 747 during takeoff may make all people onboard immediate casualties.
The chosen method of identifying risks may depend on culture, industry practice and compliance. The identification methods are formed by templates or the development of templates for identifying source, problem or event. Common risk identification methods are:
• Objectives-based risk identification] Organizations and project teams have objectives. Any event that may endanger achieving an objective partly or completely is identified as risk.
• Scenario-based risk identification In scenario analysis different scenarios are created. The scenarios may be the alternative ways to achieve an objective, or an analysis of the interaction of forces in, for example, a market or battle. Any event that triggers an undesired scenario alternative is identified as risk
• Taxonomy-based risk identification The taxonomy in taxonomy-based risk identification is a breakdown of possible risk sources. Based on the taxonomy and knowledge of best practices, a questionnaire is compiled. The answers to the questions reveal risks.[5]
• Common-risk checking In several industries lists with known risks are available. Each risk in the list can be checked for application to a particular situation.[6]
• Risk charting[7] This method combines the above approaches by listing resources at risk, Threats to those resources Modifying Factors which may increase or decrease the risk and Consequences it is wished to avoid. Creating a matrix under these headings enables a variety of approaches. One can begin with resources and consider the threats they are exposed to and the consequences of each. Alternatively one can start with the threats and examine which resources they would affect, or one can begin with the consequences and determine which combination of threats and resources would be involved to bring them about.
Assessment
Once risks have been identified, they must then be assessed as to their potential severity of loss and to the probability of occurrence. These quantities can be either simple to measure, in the case of the value of a lost building, or impossible to know for sure in the case of the probability of an unlikely event occurring. Therefore, in the assessment process it is critical to make the best educated guesses possible in order to properly prioritize the implementation of the risk management plan.
The fundamental difficulty in risk assessment is determining the rate of occurrence since statistical information is not available on all kinds of past incidents. Furthermore, evaluating the severity of the consequences (impact) is often quite difficult for immaterial assets. Asset valuation is another question that needs to be addressed. Thus, best educated opinions and available statistics are the primary sources of information. Nevertheless, risk assessment should produce such information for the management of the organization that the primary risks are easy to understand and that the risk management decisions may be prioritized. Thus, there have been several theories and attempts to quantify risks. Numerous different risk formulae exist, but perhaps the most widely accepted formula for risk quantification is:
Rate of occurrence multiplied by the impact of the event equals risk
Composite Risk Index
The above formula can also be re-written in terms of a Composite Risk Index, as follows:
Composite Risk Index = Impact of Risk event x Probability of Occurrence
The impact of the risk event is assessed on a scale of 0 to 5, where 0 and 5 represent the minimum and maximum possible impact of an occurrence of a risk (usually in terms of financial losses).
The probability of occurrence is likewise assessed on a scale from 0 to 5, where 0 represents a zero probability of the risk event actually occurring while 5 represents a 100% probability of occurrence.
The Composite Index thus can take values ranging from 0 through 25, and this range is usually arbitrarily divided into three sub-ranges. The overall risk assessment is then Low, Medium or High, depending on the sub-range containing the calculated value of the Composite Index. For instance, the three sub-ranges could be defined as 0 to 8, 9 to 16 and 17 to 25.
Note that the probability of risk occurrence is difficult to estimate since the past data on frequencies are not readily available, as mentioned above.
Likewise, the impact of the risk is not easy to estimate since it is often difficult to estimate the potential financial loss in the event of risk occurrence.
Further, both the above factors can change in magnitude depending on the adequacy of risk avoidance and prevention measures taken and due to changes in the external business environment. Hence it is absolutely necessary to periodically re-assess risks and intensify/relax mitigation measures as necessary.
Risk Options
Risk mitigation measures are usually formulated according to one or more of the following major risk options, which are:
1. Design a new business process with adequate built-in risk control and containment measures from the start.
2. Periodically re-assess risks that are accepted in ongoing processes as a normal feature of business operations and modify mitigation measures.
3. Transfer risks to an external agency (e.g. an insurance company)
4. Avoid risks altogether (e.g. by closing down a particular high-risk business area)
Later research has shown that the financial benefits of risk management are less dependent on the formula used but are more dependent on the frequency and how risk assessment is performed.
In business it is imperative to be able to present the findings of risk assessments in financial terms.
Potential risk treatments
Once risks have been identified and assessed, all techniques to manage the risk fall into one or more of these four major categories:[9]
• Avoidance (eliminate, withdraw from or not become involved)
• Reduction (optimise - mitigate)
• Sharing (transfer - outsource or insure)
• Retention (accept and budget)
Ideal use of these strategies may not be possible. Some of them may involve trade-offs that are not acceptable to the organization or person making the risk management decisions.
Risk avoidance
This includes not performing an activity that could carry risk. An example would be not buying a property or business in order to not take on the Legal liability that comes with it. Another would be not be flying in order to not take the risk that the airplane were to be hijacked. Avoidance may seem the answer to all risks, but avoiding risks also means losing out on the potential gain that accepting (retaining) the risk may have allowed. Not entering a business to avoid the risk of loss also avoids the possibility of earning profits.
Hazard Prevention
Hazard prevention refers to the prevention of risks in an emergency. The first and most effective stage of hazard prevention is the elimination of hazards. If this takes too long, is too costly, or is otherwise impractical, the second stage is mitigation.
Risk reduction
Risk reduction or "optimisation" involves reducing the severity of the loss or the likelihood of the loss from occurring. For example, sprinklers are designed to put out a fire to reduce the risk of loss by fire. This method may cause a greater loss by water damage and therefore may not be suitable. Halon fire suppression systems may mitigate that risk, but the cost may be prohibitive as a strategy.
Acknowledging that risks can be positive or negative, optimising risks means finding a balance between negative risk and the benefit of the operation or activity; and between risk reduction and effort applied. By an offshore drilling contractor effectively applying HSE Management in its organisation, it can optimise risk to achieve levels of residual risk that are tolerable.[10]
Modern software development methodologies reduce risk by developing and delivering software incrementally. Early methodologies suffered from the fact that they only delivered software in the final phase of development; any problems encountered in earlier phases meant costly rework and often jeopardized the whole project. By developing in iterations, software projects can limit effort wasted to a single iteration.
Outsourcing could be an example of risk reduction if the outsourcer can demonstrate higher capability at managing or reducing risks.[11] For example, a company may outsource only its software development, the manufacturing of hard goods, or customer support needs to another company, while handling the business management itself. This way, the company can concentrate more on business development without having to worry as much about the manufacturing process, managing the development team, or finding a physical location for a call center.
Risk sharing
Briefly defined as "sharing with another party the burden of loss or the benefit of gain, from a risk, and the measures to reduce a risk."
The term of 'risk transfer' is often used in place of risk sharing in the mistaken belief that you can transfer a risk to a third party through insurance or outsourcing. In practice if the insurance company or contractor go bankrupt or end up in court, the original risk is likely to still revert to the first party. As such in the terminology of practitioners and scholars alike, the purchase of an insurance contract is often described as a "transfer of risk." However, technically speaking, the buyer of the contract generally retains legal responsibility for the losses "transferred", meaning that insurance may be described more accurately as a post-event compensatory mechanism. For example, a personal injuries insurance policy does not transfer the risk of a car accident to the insurance company. The risk still lies with the policy holder namely the person who has been in the accident. The insurance policy simply provides that if an accident (the event) occurs involving the policy holder then some compensation may be payable to the policy holder that is commensurate to the suffering/damage.
Some ways of managing risk fall into multiple categories. Risk retention pools are technically retaining the risk for the group, but spreading it over the whole group involves transfer among individual members of the group. This is different from traditional insurance, in that no premium is exchanged between members of the group up front, but instead losses are assessed to all members of the group.
Risk retention
Involves accepting the loss, or benefit of gain, from a risk when it occurs. True self insurance falls in this category. Risk retention is a viable strategy for small risks where the cost of insuring against the risk would be greater over time than the total losses sustained. All risks that are not avoided or transferred are retained by default. This includes risks that are so large or catastrophic that they either cannot be insured against or the premiums would be infeasible. War is an example since most property and risks are not insured against war, so the loss attributed by war is retained by the insured. Also any amounts of potential loss (risk) over the amount insured is retained risk. This may also be acceptable if the chance of a very large loss is small or if the cost to insure for greater coverage amounts is so great it would hinder the goals of the organization too much.
Create a risk management plan
Select appropriate controls or countermeasures to measure each risk. Risk mitigation needs to be approved by the appropriate level of management. For instance, a risk concerning the image of the organization should have top management decision behind it whereas IT management would have the authority to decide on computer virus risks.
The risk management plan should propose applicable and effective security controls for managing the risks. For example, an observed high risk of computer viruses could be mitigated by acquiring and implementing antivirus software. A good risk management plan should contain a schedule for control implementation and responsible persons for those actions.
According to ISO/IEC 27001, the stage immediately after completion of the risk assessment phase consists of preparing a Risk Treatment Plan, which should document the decisions about how each of the identified risks should be handled. Mitigation of risks often means selection of security controls, which should be documented in a Statement of Applicability, which identifies which particular control objectives and controls from the standard have been selected, and why.
Implementation
Implementation follows all of the planned methods for mitigating the effect of the risks. Purchase insurance policies for the risks that have been decided to be transferred to an insurer, avoid all risks that can be avoided without sacrificing the entity's goals, reduce others, and retain the rest.
Review and evaluation of the plan
Initial risk management plans will never be perfect. Practice, experience, and actual loss results will necessitate changes in the plan and contribute information to allow possible different decisions to be made in dealing with the risks being faced.
Risk analysis results and management plans should be updated periodically. There are two primary reasons for this:
1. to evaluate whether the previously selected security controls are still applicable and effective, and
2. to evaluate the possible risk level changes in the business environment. For example, information risks are a good example of rapidly changing business environment.
c) What are the different risk assessment activities? Discuss anyone of them.
1. List three common types of risks that a typical software project might suffer from. Explain, how you can identify the risks that your project is susceptible to. Suppose you are the project manager of a large software development project, point out the main steps you would follow to manage risks in your software project.
2. What is project risk management? Discuss how should an organization following project management equip to cope with and overcome project risks?
3. Explain, how you can choose the best risk reduction technique when there are many ways of reducing a risk.
4. Discuss how a software project manager deals with the risk of unrealistic schedules and budgets.
5. Suppose you are the project manager of a certain software development project. Explain how you would carry out the risk analysis? What would be the outcome of the risk analysis? How would the outcome of your risk analysis be used to manage the risks?
2. The next item, unrealistic schedules and budgets, happens very frequently due to business and other reasons. It is very common that high-level management imposes a schedule for a software project that is not based on the characteristics of the project and is unrealistic. This risk applies to all projects. Project-specific risks in cost and schedule occur due to underestimating the value of some of the cost drivers. Recall the cost models like COCOMO, Function Point estimates. Even the size estimate is correct, by incorrectly estimating the value of the cost drivers; the project runs the risk of going over budget and falling behind schedule. The cost and schedule risks can be approximated by estimating the maximum value of different cost drivers along with the probability of occurrence and then estimating the possible cost and schedule overruns.
3. The next few items are related to requirements. Projects run the risk of developing the wrong software if the requirement analysis is not done properly and if development begins too early. Similarly, often improper user interface may be developed. This requires extensive rework of the user interface later or the software benefits are not obtained because users are reluctant to use it. Gold plating refers to adding features in the software that are only marginally useful. This adds unnecessary risk to the project because gold plating consumes resources and time with little return. Some requirement changes are to be expected in any project, but some time frequent changes are requested, which is often a reflection of the fact that the client has not yet understood or settled on its own requirements. The effect of requirement changes is substantial in terms of cost, especially if the changes occur when the project has progressed to later phases. Performance shortfalls are critical in real-time systems and poor performance can mean the failure of the project.
4. If a project depends on externally available components – either to be provided by the client or to be procured as an off-the shelf component or dependency with other services – the project runs some risks. The project might be delayed if the external component is not available on time. The project would also suffer if the quality of the external component is poor or if the component turns out to be incompatible with the other project components or with the environment in which the software is developed or is to operate. If a project relies on technology that is not well developed, it may fail. This is a risk due to straining the computer science capabilities.
5. Using the checklist of the top-10 risk items is one way to identify risks. This approach is likely to suffice in many projects. The other methods are decision driver analysis, assumption analysis and decomposition. Decision driver analysis involves questioning and analyzing all the major decisions taken for the project. If a decision has been driven by factors other than technical and management reasons, it is likely to be a source of risk in the project. Such decisions may driven by politics, marketing, or the desire for short-term gain. Optimistic assumptions made about the project also are a source of risk. Some such optimistic assumptions are that nothing will go wrong in the project, no personnel will quit during the project, people will put in extra hours if required, and all external components (hardware and software) will be delivered on time. Identifying such assumptions will point out the source of risks. An effective method for identifying these hidden assumptions is comparing them with past experience. Decomposition implies breaking a large project into clearly defined parts and then analyzing them. Many software systems have the phenomenon that 20% of the modules cause 80% of the project problems. Decomposition will help identify these modules.
Evaluating and Managing the Risks You Face
Almost everything we do in today's business world involves a risk of some kind: customer habits change, new competitors appear, factors outside your control could delay your project. But formal risk analysis and risk management can help you to assess these risks and decide what actions to take to minimize disruptions to your plans. They will also help you to decide whether the strategies you could use to control risk are cost-effective.
How to use the tool:
Here we define risk as 'the perceived extent of possible loss'. Different people will have different views of the impact of a particular risk – what may be a small risk for one person may destroy the livelihood of someone else.
One way of putting figures to risk is to calculate a value for it as:
risk = probability of event x cost of event
Doing this allows you to compare risks objectively. We use this approach formally in decision making with Decision Trees.
To carry out a risk analysis, follow these steps:
1. Identify Threats:
The first stage of a risk analysis is to identify threats facing you. Threats may be:
• Human - from individuals or organizations, illness, death, etc.
• Operational - from disruption to supplies and operations, loss of access to essential assets, failures in distribution, etc.
• Reputational - from loss of business partner or employee confidence, or damage to reputation in the market.
• Procedural - from failures of accountability, internal systems and controls, organization, fraud, etc.
• Project - risks of cost over-runs, jobs taking too long, of insufficient product or service quality, etc.
• Financial - from business failure, stock market, interest rates, unemployment, etc.
• Technical - from advances in technology, technical failure, etc.
• Natural - threats from weather, natural disaster, accident, disease, etc.
• Political - from changes in tax regimes, public opinion, government policy, foreign influence, etc.
• Others - Porter's Five Forces analysis may help you identify other risks.
This analysis of threat is important because it is so easy to overlook important threats. One way of trying to capture them all is to use a number of different approaches:
• Firstly, run through a list such as the one above, to see if any apply
• Secondly, think through the systems, organizations or structures you operate, and analyze risks to any part of those
• See if you can see any vulnerabilities within these systems or structures
• Ask other people, who might have different perspectives.
2. Estimate Risk:
Once you have identified the threats you face, the next step is to work out the likelihood of the threat being realized and to assess its impact.
One approach to this is to make your best estimate of the probability of the event occurring, and to multiply this by the amount it will cost you to set things right if it happens. This gives you a value for the risk.
3. Managing Risk:
Once you have worked out the value of risks you face, you can start to look at ways of managing them. When you are doing this, it is important to choose cost effective approaches - in most cases, there is no point in spending more to eliminating a risk than the cost of the event if it occurs. Often, it may be better to accept the risk than to use excessive resources to eliminate it.
Risk may be managed in a number of ways:
• By using existing assets:
Here existing resources can be used to counter risk. This may involve improvements to existing methods and systems, changes in responsibilities, improvements to accountability and internal controls, etc.
• By contingency planning:
You may decide to accept a risk, but choose to develop a plan to minimize its effects if it happens. A good contingency plan will allow you to take action immediately, with the minimum of project control if you find yourself in a crisis management situation. Contingency plans also form a key part of Business Continuity Planning (BCP) or Business Continuity management (BCM).
• By investing in new resources:
Your risk analysis should give you the basis for deciding whether to bring in additional resources to counter the risk. This can also include insuring the risk: Here you pay someone else to carry part of the risk - this is particularly important where the risk is so great as to threaten your or your organization's solvency.
4. Reviews:
Once you have carried out a risk analysis and management exercise, it may be worth carrying out regular reviews. These might involve formal reviews of the risk analysis, or may involve testing systems and plans appropriately.
Key points:
Risk analysis allows you to examine the risks that you or your organization face. It is based on a structured approach to thinking through threats, followed by an evaluation of the probability and cost of events occurring.
As such, it forms the basis for risk management and crisis prevention. Here the emphasis is on cost effectiveness. Risk management involves adapting the use of existing resources, contingency planning and good use of new resources.
Risk are future uncertain events with a probability of occurrence and a potential for loss”. Risk identification and management are the main concerns in every software project. Effective analysis of software risks will help to effective planning and assignments of work. Risks are identified, classified and managed before actual execution of program. These risks are classified in different categories.
Risk management should:
• create value
• be an integral part of organizational processes
• be part of decision making
• explicitly address uncertainty
• be systematic and structured
• be based on the best available information
• be tailored
• take into account human factors
• be transparent and inclusive
• be dynamic, iterative and responsive to change
• be capable of continual improvement and enhancement
Categories of risks:
Schedule Risk:
Project schedule get slip when project tasks and schedule release risks are not addressed properly.
Schedule risks mainly affect on project and finally on company economy and may lead to project failure.
Schedules often slip due to following reasons:
• Wrong time estimation
• Resources are not tracked properly. All resources like staff, systems, skills of individuals etc.
• Failure to identify complex functionalities and time required to develop those functionalities.
• Unexpected project scope expansions.
Budget Risk:• Wrong budget estimation.
• Cost overruns
• Project scope expansion
Operational Risks:
Risks of loss due to improper process implementation, failed system or some external events risks.
Causes of Operational risks:• Failure to address priority conflicts
• Failure to resolve the responsibilities
• Insufficient resources
• No proper subject training
• No resource planning
• No communication in team.
Technical risks:
Technical risks generally leads to failure of functionality and performance.
Causes of technical risks are:
• Continuous changing requirements
• No advanced technology available or the existing technology is in initial stages.
• Product is complex to implement.
• Difficult project modules integration.
Programmatic Risks:
These are the external risks beyond the operational limits. These are all uncertain risks are outside the control of the program.
These external events can be:
• Running out of fund.
• Market development
• Changing customer product strategy and priority
• Government rule changes
Identification
After establishing the context, the next step in the process of managing risk is to identify potential risks. Risks are about events that, when triggered, cause problems. Hence, risk identification can start with the source of problems, or with the problem itself.
• Source analysis] Risk sources may be internal or external to the system that is the target of risk management.
Examples of risk sources are: stakeholders of a project, employees of a company or the weather over an airport.
• Problem analysis Risks are related to identified threats. For example: the threat of losing money, the threat of abuse of privacy information or the threat of accidents and casualties. The threats may exist with various entities, most important with shareholders, customers and legislative bodies such as the government.
When either source or problem is known, the events that a source may trigger or the events that can lead to a problem can be investigated. For example: stakeholders withdrawing during a project may endanger funding of the project; privacy information may be stolen by employees even within a closed network; lightning striking a Boeing 747 during takeoff may make all people onboard immediate casualties.
The chosen method of identifying risks may depend on culture, industry practice and compliance. The identification methods are formed by templates or the development of templates for identifying source, problem or event. Common risk identification methods are:
• Objectives-based risk identification] Organizations and project teams have objectives. Any event that may endanger achieving an objective partly or completely is identified as risk.
• Scenario-based risk identification In scenario analysis different scenarios are created. The scenarios may be the alternative ways to achieve an objective, or an analysis of the interaction of forces in, for example, a market or battle. Any event that triggers an undesired scenario alternative is identified as risk
• Taxonomy-based risk identification The taxonomy in taxonomy-based risk identification is a breakdown of possible risk sources. Based on the taxonomy and knowledge of best practices, a questionnaire is compiled. The answers to the questions reveal risks.[5]
• Common-risk checking In several industries lists with known risks are available. Each risk in the list can be checked for application to a particular situation.[6]
• Risk charting[7] This method combines the above approaches by listing resources at risk, Threats to those resources Modifying Factors which may increase or decrease the risk and Consequences it is wished to avoid. Creating a matrix under these headings enables a variety of approaches. One can begin with resources and consider the threats they are exposed to and the consequences of each. Alternatively one can start with the threats and examine which resources they would affect, or one can begin with the consequences and determine which combination of threats and resources would be involved to bring them about.
Assessment
Once risks have been identified, they must then be assessed as to their potential severity of loss and to the probability of occurrence. These quantities can be either simple to measure, in the case of the value of a lost building, or impossible to know for sure in the case of the probability of an unlikely event occurring. Therefore, in the assessment process it is critical to make the best educated guesses possible in order to properly prioritize the implementation of the risk management plan.
The fundamental difficulty in risk assessment is determining the rate of occurrence since statistical information is not available on all kinds of past incidents. Furthermore, evaluating the severity of the consequences (impact) is often quite difficult for immaterial assets. Asset valuation is another question that needs to be addressed. Thus, best educated opinions and available statistics are the primary sources of information. Nevertheless, risk assessment should produce such information for the management of the organization that the primary risks are easy to understand and that the risk management decisions may be prioritized. Thus, there have been several theories and attempts to quantify risks. Numerous different risk formulae exist, but perhaps the most widely accepted formula for risk quantification is:
Rate of occurrence multiplied by the impact of the event equals risk
Composite Risk Index
The above formula can also be re-written in terms of a Composite Risk Index, as follows:
Composite Risk Index = Impact of Risk event x Probability of Occurrence
The impact of the risk event is assessed on a scale of 0 to 5, where 0 and 5 represent the minimum and maximum possible impact of an occurrence of a risk (usually in terms of financial losses).
The probability of occurrence is likewise assessed on a scale from 0 to 5, where 0 represents a zero probability of the risk event actually occurring while 5 represents a 100% probability of occurrence.
The Composite Index thus can take values ranging from 0 through 25, and this range is usually arbitrarily divided into three sub-ranges. The overall risk assessment is then Low, Medium or High, depending on the sub-range containing the calculated value of the Composite Index. For instance, the three sub-ranges could be defined as 0 to 8, 9 to 16 and 17 to 25.
Note that the probability of risk occurrence is difficult to estimate since the past data on frequencies are not readily available, as mentioned above.
Likewise, the impact of the risk is not easy to estimate since it is often difficult to estimate the potential financial loss in the event of risk occurrence.
Further, both the above factors can change in magnitude depending on the adequacy of risk avoidance and prevention measures taken and due to changes in the external business environment. Hence it is absolutely necessary to periodically re-assess risks and intensify/relax mitigation measures as necessary.
Risk Options
Risk mitigation measures are usually formulated according to one or more of the following major risk options, which are:
1. Design a new business process with adequate built-in risk control and containment measures from the start.
2. Periodically re-assess risks that are accepted in ongoing processes as a normal feature of business operations and modify mitigation measures.
3. Transfer risks to an external agency (e.g. an insurance company)
4. Avoid risks altogether (e.g. by closing down a particular high-risk business area)
Later research has shown that the financial benefits of risk management are less dependent on the formula used but are more dependent on the frequency and how risk assessment is performed.
In business it is imperative to be able to present the findings of risk assessments in financial terms.
Potential risk treatments
Once risks have been identified and assessed, all techniques to manage the risk fall into one or more of these four major categories:[9]
• Avoidance (eliminate, withdraw from or not become involved)
• Reduction (optimise - mitigate)
• Sharing (transfer - outsource or insure)
• Retention (accept and budget)
Ideal use of these strategies may not be possible. Some of them may involve trade-offs that are not acceptable to the organization or person making the risk management decisions.
Risk avoidance
This includes not performing an activity that could carry risk. An example would be not buying a property or business in order to not take on the Legal liability that comes with it. Another would be not be flying in order to not take the risk that the airplane were to be hijacked. Avoidance may seem the answer to all risks, but avoiding risks also means losing out on the potential gain that accepting (retaining) the risk may have allowed. Not entering a business to avoid the risk of loss also avoids the possibility of earning profits.
Hazard Prevention
Hazard prevention refers to the prevention of risks in an emergency. The first and most effective stage of hazard prevention is the elimination of hazards. If this takes too long, is too costly, or is otherwise impractical, the second stage is mitigation.
Risk reduction
Risk reduction or "optimisation" involves reducing the severity of the loss or the likelihood of the loss from occurring. For example, sprinklers are designed to put out a fire to reduce the risk of loss by fire. This method may cause a greater loss by water damage and therefore may not be suitable. Halon fire suppression systems may mitigate that risk, but the cost may be prohibitive as a strategy.
Acknowledging that risks can be positive or negative, optimising risks means finding a balance between negative risk and the benefit of the operation or activity; and between risk reduction and effort applied. By an offshore drilling contractor effectively applying HSE Management in its organisation, it can optimise risk to achieve levels of residual risk that are tolerable.[10]
Modern software development methodologies reduce risk by developing and delivering software incrementally. Early methodologies suffered from the fact that they only delivered software in the final phase of development; any problems encountered in earlier phases meant costly rework and often jeopardized the whole project. By developing in iterations, software projects can limit effort wasted to a single iteration.
Outsourcing could be an example of risk reduction if the outsourcer can demonstrate higher capability at managing or reducing risks.[11] For example, a company may outsource only its software development, the manufacturing of hard goods, or customer support needs to another company, while handling the business management itself. This way, the company can concentrate more on business development without having to worry as much about the manufacturing process, managing the development team, or finding a physical location for a call center.
Risk sharing
Briefly defined as "sharing with another party the burden of loss or the benefit of gain, from a risk, and the measures to reduce a risk."
The term of 'risk transfer' is often used in place of risk sharing in the mistaken belief that you can transfer a risk to a third party through insurance or outsourcing. In practice if the insurance company or contractor go bankrupt or end up in court, the original risk is likely to still revert to the first party. As such in the terminology of practitioners and scholars alike, the purchase of an insurance contract is often described as a "transfer of risk." However, technically speaking, the buyer of the contract generally retains legal responsibility for the losses "transferred", meaning that insurance may be described more accurately as a post-event compensatory mechanism. For example, a personal injuries insurance policy does not transfer the risk of a car accident to the insurance company. The risk still lies with the policy holder namely the person who has been in the accident. The insurance policy simply provides that if an accident (the event) occurs involving the policy holder then some compensation may be payable to the policy holder that is commensurate to the suffering/damage.
Some ways of managing risk fall into multiple categories. Risk retention pools are technically retaining the risk for the group, but spreading it over the whole group involves transfer among individual members of the group. This is different from traditional insurance, in that no premium is exchanged between members of the group up front, but instead losses are assessed to all members of the group.
Risk retention
Involves accepting the loss, or benefit of gain, from a risk when it occurs. True self insurance falls in this category. Risk retention is a viable strategy for small risks where the cost of insuring against the risk would be greater over time than the total losses sustained. All risks that are not avoided or transferred are retained by default. This includes risks that are so large or catastrophic that they either cannot be insured against or the premiums would be infeasible. War is an example since most property and risks are not insured against war, so the loss attributed by war is retained by the insured. Also any amounts of potential loss (risk) over the amount insured is retained risk. This may also be acceptable if the chance of a very large loss is small or if the cost to insure for greater coverage amounts is so great it would hinder the goals of the organization too much.
Create a risk management plan
Select appropriate controls or countermeasures to measure each risk. Risk mitigation needs to be approved by the appropriate level of management. For instance, a risk concerning the image of the organization should have top management decision behind it whereas IT management would have the authority to decide on computer virus risks.
The risk management plan should propose applicable and effective security controls for managing the risks. For example, an observed high risk of computer viruses could be mitigated by acquiring and implementing antivirus software. A good risk management plan should contain a schedule for control implementation and responsible persons for those actions.
According to ISO/IEC 27001, the stage immediately after completion of the risk assessment phase consists of preparing a Risk Treatment Plan, which should document the decisions about how each of the identified risks should be handled. Mitigation of risks often means selection of security controls, which should be documented in a Statement of Applicability, which identifies which particular control objectives and controls from the standard have been selected, and why.
Implementation
Implementation follows all of the planned methods for mitigating the effect of the risks. Purchase insurance policies for the risks that have been decided to be transferred to an insurer, avoid all risks that can be avoided without sacrificing the entity's goals, reduce others, and retain the rest.
Review and evaluation of the plan
Initial risk management plans will never be perfect. Practice, experience, and actual loss results will necessitate changes in the plan and contribute information to allow possible different decisions to be made in dealing with the risks being faced.
Risk analysis results and management plans should be updated periodically. There are two primary reasons for this:
1. to evaluate whether the previously selected security controls are still applicable and effective, and
2. to evaluate the possible risk level changes in the business environment. For example, information risks are a good example of rapidly changing business environment.
c) What are the different risk assessment activities? Discuss anyone of them.
1. List three common types of risks that a typical software project might suffer from. Explain, how you can identify the risks that your project is susceptible to. Suppose you are the project manager of a large software development project, point out the main steps you would follow to manage risks in your software project.
2. What is project risk management? Discuss how should an organization following project management equip to cope with and overcome project risks?
3. Explain, how you can choose the best risk reduction technique when there are many ways of reducing a risk.
4. Discuss how a software project manager deals with the risk of unrealistic schedules and budgets.
5. Suppose you are the project manager of a certain software development project. Explain how you would carry out the risk analysis? What would be the outcome of the risk analysis? How would the outcome of your risk analysis be used to manage the risks?
2. The next item, unrealistic schedules and budgets, happens very frequently due to business and other reasons. It is very common that high-level management imposes a schedule for a software project that is not based on the characteristics of the project and is unrealistic. This risk applies to all projects. Project-specific risks in cost and schedule occur due to underestimating the value of some of the cost drivers. Recall the cost models like COCOMO, Function Point estimates. Even the size estimate is correct, by incorrectly estimating the value of the cost drivers; the project runs the risk of going over budget and falling behind schedule. The cost and schedule risks can be approximated by estimating the maximum value of different cost drivers along with the probability of occurrence and then estimating the possible cost and schedule overruns.
3. The next few items are related to requirements. Projects run the risk of developing the wrong software if the requirement analysis is not done properly and if development begins too early. Similarly, often improper user interface may be developed. This requires extensive rework of the user interface later or the software benefits are not obtained because users are reluctant to use it. Gold plating refers to adding features in the software that are only marginally useful. This adds unnecessary risk to the project because gold plating consumes resources and time with little return. Some requirement changes are to be expected in any project, but some time frequent changes are requested, which is often a reflection of the fact that the client has not yet understood or settled on its own requirements. The effect of requirement changes is substantial in terms of cost, especially if the changes occur when the project has progressed to later phases. Performance shortfalls are critical in real-time systems and poor performance can mean the failure of the project.
4. If a project depends on externally available components – either to be provided by the client or to be procured as an off-the shelf component or dependency with other services – the project runs some risks. The project might be delayed if the external component is not available on time. The project would also suffer if the quality of the external component is poor or if the component turns out to be incompatible with the other project components or with the environment in which the software is developed or is to operate. If a project relies on technology that is not well developed, it may fail. This is a risk due to straining the computer science capabilities.
5. Using the checklist of the top-10 risk items is one way to identify risks. This approach is likely to suffice in many projects. The other methods are decision driver analysis, assumption analysis and decomposition. Decision driver analysis involves questioning and analyzing all the major decisions taken for the project. If a decision has been driven by factors other than technical and management reasons, it is likely to be a source of risk in the project. Such decisions may driven by politics, marketing, or the desire for short-term gain. Optimistic assumptions made about the project also are a source of risk. Some such optimistic assumptions are that nothing will go wrong in the project, no personnel will quit during the project, people will put in extra hours if required, and all external components (hardware and software) will be delivered on time. Identifying such assumptions will point out the source of risks. An effective method for identifying these hidden assumptions is comparing them with past experience. Decomposition implies breaking a large project into clearly defined parts and then analyzing them. Many software systems have the phenomenon that 20% of the modules cause 80% of the project problems. Decomposition will help identify these modules.
Evaluating and Managing the Risks You Face
Almost everything we do in today's business world involves a risk of some kind: customer habits change, new competitors appear, factors outside your control could delay your project. But formal risk analysis and risk management can help you to assess these risks and decide what actions to take to minimize disruptions to your plans. They will also help you to decide whether the strategies you could use to control risk are cost-effective.
How to use the tool:
Here we define risk as 'the perceived extent of possible loss'. Different people will have different views of the impact of a particular risk – what may be a small risk for one person may destroy the livelihood of someone else.
One way of putting figures to risk is to calculate a value for it as:
risk = probability of event x cost of event
Doing this allows you to compare risks objectively. We use this approach formally in decision making with Decision Trees.
To carry out a risk analysis, follow these steps:
1. Identify Threats:
The first stage of a risk analysis is to identify threats facing you. Threats may be:
• Human - from individuals or organizations, illness, death, etc.
• Operational - from disruption to supplies and operations, loss of access to essential assets, failures in distribution, etc.
• Reputational - from loss of business partner or employee confidence, or damage to reputation in the market.
• Procedural - from failures of accountability, internal systems and controls, organization, fraud, etc.
• Project - risks of cost over-runs, jobs taking too long, of insufficient product or service quality, etc.
• Financial - from business failure, stock market, interest rates, unemployment, etc.
• Technical - from advances in technology, technical failure, etc.
• Natural - threats from weather, natural disaster, accident, disease, etc.
• Political - from changes in tax regimes, public opinion, government policy, foreign influence, etc.
• Others - Porter's Five Forces analysis may help you identify other risks.
This analysis of threat is important because it is so easy to overlook important threats. One way of trying to capture them all is to use a number of different approaches:
• Firstly, run through a list such as the one above, to see if any apply
• Secondly, think through the systems, organizations or structures you operate, and analyze risks to any part of those
• See if you can see any vulnerabilities within these systems or structures
• Ask other people, who might have different perspectives.
2. Estimate Risk:
Once you have identified the threats you face, the next step is to work out the likelihood of the threat being realized and to assess its impact.
One approach to this is to make your best estimate of the probability of the event occurring, and to multiply this by the amount it will cost you to set things right if it happens. This gives you a value for the risk.
3. Managing Risk:
Once you have worked out the value of risks you face, you can start to look at ways of managing them. When you are doing this, it is important to choose cost effective approaches - in most cases, there is no point in spending more to eliminating a risk than the cost of the event if it occurs. Often, it may be better to accept the risk than to use excessive resources to eliminate it.
Risk may be managed in a number of ways:
• By using existing assets:
Here existing resources can be used to counter risk. This may involve improvements to existing methods and systems, changes in responsibilities, improvements to accountability and internal controls, etc.
• By contingency planning:
You may decide to accept a risk, but choose to develop a plan to minimize its effects if it happens. A good contingency plan will allow you to take action immediately, with the minimum of project control if you find yourself in a crisis management situation. Contingency plans also form a key part of Business Continuity Planning (BCP) or Business Continuity management (BCM).
• By investing in new resources:
Your risk analysis should give you the basis for deciding whether to bring in additional resources to counter the risk. This can also include insuring the risk: Here you pay someone else to carry part of the risk - this is particularly important where the risk is so great as to threaten your or your organization's solvency.
4. Reviews:
Once you have carried out a risk analysis and management exercise, it may be worth carrying out regular reviews. These might involve formal reviews of the risk analysis, or may involve testing systems and plans appropriately.
Key points:
Risk analysis allows you to examine the risks that you or your organization face. It is based on a structured approach to thinking through threats, followed by an evaluation of the probability and cost of events occurring.
As such, it forms the basis for risk management and crisis prevention. Here the emphasis is on cost effectiveness. Risk management involves adapting the use of existing resources, contingency planning and good use of new resources.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.