Risk analysis (business): Difference between revisions
mNo edit summary |
Fixed some irritating grammar weirdness. Should probably have a professional look over the changes. |
||
| Line 15: | Line 15: | ||
After identifying and categorizing risks, a team identifies the controls that could mitigate the risk. The decision for what controls are needed lies with the business manager. The team's conclusions as to what risks exists and what controls needed are documented along with a related action plan for control implementation. |
After identifying and categorizing risks, a team identifies the controls that could mitigate the risk. The decision for what controls are needed lies with the business manager. The team's conclusions as to what risks exists and what controls needed are documented along with a related action plan for control implementation. |
||
Three of the most important [[risks]] a software company faces are unexpected changes in revenue |
Three of the most important [[risks]] a software company faces are: unexpected changes in revenue, unexpected changes in costs from those budgeted and the amount of specialization of the software planned. Risks that affect revenues can be: unanticipated competition, privacy, intellectual property right problems, and unit sales that are less than forecast. Unexpected development costs also create risk that can be in the form of more rework than anticipated, security holes, and privacy invasions. |
||
<ref>{{cite journal |
<ref>{{cite journal |
||
|author=Messerschmitt, D. G. and C. Szyperski|title=Marketplace Issues in Software Planning and Design|journal=IEEE Software|volume=21|issue=3|month=May/June|year=2004|pages=62–70|doi=10.1109/MS.2004.1293074}}</ref> |
|author=Messerschmitt, D. G. and C. Szyperski|title=Marketplace Issues in Software Planning and Design|journal=IEEE Software|volume=21|issue=3|month=May/June|year=2004|pages=62–70|doi=10.1109/MS.2004.1293074}}</ref> |
||
Narrow specialization of software with a large amount of research and development expenditures can lead both business and technological risks since specialization does not lead to lower unit costs of software.<ref>{{cite journal |
Narrow specialization of software with a large amount of research and development expenditures can lead to both business and technological risks since specialization does not necessarily lead to lower unit costs of software.<ref>{{cite journal |
||
|author=Rao, P.M., and J. A. Klein|title=Growing importance of marketing strategies for the software industry|journal=Industrial marketing management|volume=23|issue=1|month=February|year=1994|pages=29–37|doi=10.1016/0019-8501(94)90024-8}}</ref> |
|author=Rao, P.M., and J. A. Klein|title=Growing importance of marketing strategies for the software industry|journal=Industrial marketing management|volume=23|issue=1|month=February|year=1994|pages=29–37|doi=10.1016/0019-8501(94)90024-8}}</ref> |
||
Combined with the decrease in the potential customer base, specialization risk can be significant for a software firm. After probabilities of scenarios have been calculated with risk analysis, the process of [[risk management]] can be applied to help manage the risk. |
Combined with the decrease in the potential customer base, specialization risk can be significant for a software firm. After probabilities of scenarios have been calculated with risk analysis, the process of [[risk management]] can be applied to help manage the risk. |
||
Revision as of 14:56, 22 October 2009
Risk analysis is a technique to identify and assess factors that may jeopardize the success of a project or achieving a goal. This technique also helps to define preventive measures to reduce the probability of these factors from occurring and identify countermeasures to successfully deal with these constraints when they develop to avert possible negative effects on the competitiveness of the company.
One of the more popular methods to perform a risk analysis in the computer field is called Facilitated Risk Analysis Process (FRAP).
Facilitated Risk Analysis Process
FRAP analyzes one system, application or segment of business processes at time.
FRAP assumes that additional efforts to develop precisely quantified risks are not cost effective because:
- such estimates are time consuming
- risk documentation becomes too voluminous for practical use
- specific loss estimates are generally not needed to determine if controls are needed.
After identifying and categorizing risks, a team identifies the controls that could mitigate the risk. The decision for what controls are needed lies with the business manager. The team's conclusions as to what risks exists and what controls needed are documented along with a related action plan for control implementation.
Three of the most important risks a software company faces are: unexpected changes in revenue, unexpected changes in costs from those budgeted and the amount of specialization of the software planned. Risks that affect revenues can be: unanticipated competition, privacy, intellectual property right problems, and unit sales that are less than forecast. Unexpected development costs also create risk that can be in the form of more rework than anticipated, security holes, and privacy invasions. [1]
Narrow specialization of software with a large amount of research and development expenditures can lead to both business and technological risks since specialization does not necessarily lead to lower unit costs of software.[2] Combined with the decrease in the potential customer base, specialization risk can be significant for a software firm. After probabilities of scenarios have been calculated with risk analysis, the process of risk management can be applied to help manage the risk.
Methods like Applied Information Economics add to and improve on risk analysis methods by introducing procedures to adjust subjective probabilities, compute the value of additional information and to use the results in part of a larger portfolio management problem.
See also
References
- Doug Hubbard (1998). "Hurdling Risk". CIO Magazine.
- ^ Messerschmitt, D. G. and C. Szyperski (2004). "Marketplace Issues in Software Planning and Design". IEEE Software. 21 (3): 62–70. doi:10.1109/MS.2004.1293074.
{{cite journal}}: Unknown parameter|month=ignored (help) - ^ Rao, P.M., and J. A. Klein (1994). "Growing importance of marketing strategies for the software industry". Industrial marketing management. 23 (1): 29–37. doi:10.1016/0019-8501(94)90024-8.
{{cite journal}}: Unknown parameter|month=ignored (help)CS1 maint: multiple names: authors list (link)