Risk Analysis: The Most Important Risk Management Stage
R
Introduction
As part of the Risk Management process, Risk Analysis is conducted during the Analyzation Stage of the hefty System Development Life Cycle causing the risk analysis stage to often be neglected by IS project managers. Many managers provide most of their attention and resources to the risk mitigation stage of the Risk Management process, instead of applying the required time and resources towards analyzing potential risks that jeopardize the success of IS projects.
However, if IS managers were to allocate the necessary attention and resources towards making the proper analyses of the risks, the risk mitigation strategies would be more efficient. A proper risk analysis will give the IS managers insight into which risks have the heaviest consequences and are considered high priority risks. Then, the managers can further allocate the necessary resources towards the risk mitigation strategies aimed towards mitigating the highest priority risks.
My academic literature will cover the Risk Management process and the impact risk analysis has upon the information systems analysis conducted by IS project managers. This academic literature first briefly covers and provides an example of the risk identification stage, the risk analysis stage, the control and documentation stage, and the risk mitigation stage. The overall focus of this academic literature is to thoroughly convey the significant impact the three risk management stages has on the risk mitigation stage, which minimizes the probability of loss. Furthermore, this academic literature more specifically conveys how impactful the risk analysis stage is when minimizing and mitigating these risks that could adversely affect the attainment of information system project objectives and that could cause loss to a company.
A proper iteration of the Risk Management process is verified by the successful formulation of risk mitigation strategies, such as implementing cyber security defense systems. These risk mitigation strategies are needed because they are the first line and last line of defense when it comes to protecting the interest of the company stakeholders. The stakeholders of a company form the backbone to the frame that keeps the company thriving, as depicted by Pinto. Without the proper risk mitigation strategies to negate harm resulting from risk threat events that occur, stakeholders would be less entitled to invest in companies, ultimately causing companies a loss in future revenues and growth that would have been generated with the stakeholder investments. As the NIST team states, “ Such harm can be experienced by a variety of organizational and non-organizational stakeholders including, for example, heads of agencies, mission and business owners, information owners/stewards, mission/business process owners, information system owners, or individuals/groups in the public or private sectors relying on the organization—in essence, anyone with a vested interest in the organization’s operations, assets, or individuals, including other organizations in partnership with the organization, or the Nation.”
R
RISK MANAGEMENT: A FOUR-STAGE PROCESS
Risk is typically linked with terms and phrases such as: probability of, degree of, measure of, exposure of, and so on. The end nouns to the linkage terms are usually negatively toned words such as: losses, damages, failures, undesired outcomes, and so on. However, risk can be linked to outcomes that are not necessarily hazardous for a company, but rather the outcome was different from what the projections forecasted. For a project manager, essentially risk is any type of hazard or non-projected outcome that can be given an estimated degree of probability to affect the attainment of project objectives.
The four stages to properly handle these risks presented to IS project managers are: the risk identification stage, the risk analysis stage, the risk mitigation strategies stage, and the control and documentation stage. (Pinto)
R
Risk Identification Stage
The systematic risk management process begins with the risk identification stage. The Risk identification stage is the process of determining the predisposing risk conditions that can reasonably be expected to affect your IS project objectives. In order to identify these risk conditions, the IS project team needs to address how the organization “frames risk” or “describes the environment in which risk-based decisions are made”, as illustrated by the NIST team. This framework will provide the project manager with insight to the organization’s risk perceptions that guides the organization’s investment and operational decisions. (NIST team) With knowledge to how the organization’s investment and operational decisions are affected by risks, the project manager will have a better idea of what the predisposing conditions are that make the information system vulnerable to threat events. Furthermore, with the proper completion of the risk identification stage, the project manager should be able to classify the predisposing risk conditions, including investment (financial) risks and operational (technical) risks.
R
Risk Analysis Stage
The Risk Analysis Stage follows the can be further broken down into the probability and Consequence Phase, Risk Impact Assessment Phase, and the Risk Prioritization Phase. The Analysis of probability and consequences phase will determine the potential impact of these identified risk conditions and determine which risk conditions have the potential to eventually progress into organizational risks. The determination is based on magnitude of vulnerability these potential risk conditions create (refer to ‘Image D’ for predisposing risk conditions). The higher the level of vulnerability the greater the chance a threat source (refer to ‘Image E’ for threat source types) can initiate a threat event and exploit the information system causing an adverse impact (refer to ‘Image F’ for impact types), which can lead to an organizational risk. In order to determine the probability of occurrence of the threat events and the impact of the threat events, the project manager must use these risk conditions as inputs in the risk analysis process, as depicted by ‘Image A’ (NIST). After deciphering the probabilities and consequences of successful threat events, the risks are prioritized to establish a ‘most-to-least’ critical importance ranking, as suggested by ‘Image B’ (MITRE team). The risks with the highest consequences and importance provides managers insight to where resources are needed most in order to mitigate these risks.
R
(Image A) (See Glossary for ‘Image A’ terms)
R
(Image B)
R
Risk Mitigation Stage
As mentioned, the risk mitigation strategies are the last line of defense for an organization and the IS project manager. The risk mitigation strategies are the carried out action plans that include the steps taken to minimize the potential impact of those properly analyzed risk conditions that are formulated into full blown risks deemed sufficiently threatening to the success of the project.
R
Control and Documentation Stage
Finally, the control and documentation stage creates a knowledge base for future projects based on lessons learned from the identified, analyzed, and mitigated risks.
A real life example of an industry that depends heavily on the IS Control and Documentation stage is the aviation industry. Throughout history, aviation information systems developed via trial and error. According to the AOPA foundation, the aviation information system’s standards developed as a result of learning from documented past incidents, often horrific accidents. For instance, the 1956’ collision of a DC-7 with a Lockheed Constellation collided over the Grand Canyon brought forth the modernization of the air traffic control system. The 1978’ collision of a Boeing 727 and a Cessna 172 brought forth tighter restrictions on flights in heavily trafficked areas. The 1986 collision of a DC-9 and a single-engine Piper brought forth the Airport and Airway Safety Expansion Act, which requires all civil air carrier aircrafts to be equipped with IS Traffic Alert and Collision Avoidance Systems (TCAS).
R
R
Critical Analysis of Risk Analyses and Mitigation Strategies examples by Risk type:
R
Financial Risk
Financial Risk
R
Financial Risk Planning
As depicted by Grable, there are two “general schools of thought” towards the financial planning process of companies and or for individuals, which are orientated by a cash flow basis or by a goal-base financial planning scheme. The cash flow basis of financial planning is "shaped by a thorough analysis of a client's goal, aspirations, time horizon, risk attitude, and other factors, with an emphasis on how goals can be funded over time through cash-flow allocations." Grable iterates that the Cash Flow basis of financial planning was the more traditional method, however, Grable states that the goal- based financial planning scheme has become the more popular approach for IS project managers.
This increase in popularity is due to IS project managers building IS projects that are designed to fund current and future liability needs, further suggesting that risk analysis is the crucial stage for realizing where resources, such as financial resources, are needed most. The potential project methods and processes are then ranked from a risk tolerance point of view as stated by Grable. Once ranked, the goals and the means of achieving these IS goals are evaluated in the context of client’s balance sheet, rather than through a cash-flow analysis. Thus, by using information off the balance sheet rather than through a cash flow analysis, a manger can see which potential IS project plans of actions give the project the best chance of success financially, as Grable states, “It is this last point that makes goal- based financial planning unique. This approach to planning can be quite beneficial as a way to determine the likelihood of planning success by matching assets to specific goals.”
R
Insight to the Possible Financial Risks
Once the goal-base financial planning has been assessed, the ranking of the project actions can be formulated, allowing for the project manager to have project insights of the possible financial risks. These financial risks are a result of IS project assets transactions, which are affected by risk factors that determine financial prices and rates, such as: interest rates, exchange rates, and commodities prices. (Horcher) These financial risks can often trickle down into the project funds that are used to pay for the needed IS resources, such as: IS database and server equipment, homegrown or foreign outsourcing, onshore or offshore facilities, and etc. Such financial risk factors that often play a role in the trickle down affect includes: interest rate fluctuations and exchange rate fluctuations. Interest rate risk is the chance of an unfavorable outcome resulting when the interest rate fluctuates. Both borrowers and investors are affected by interest rate risk. (Horcher) Interest rate risks become relevant when the organization has to borrower the funds to pay for the required IS resources needed to carry out the project action plans. Exchange rates can be used to mitigate risk because lower foreign interest rates might be seen as a way to reduce financial costs. (Horcher) However, exchange rates may also be unfavorable and can adversely affect the IS project financially.
R
Fundable Project Action Plans
In order to combat these fluctuations of various financial rate risks, an IS project manager needs to pick fundable project action plans that balance one another through the riskiness of the assets used; thus a process of offsetting assets. Hedging is the term used for offsetting assets and is one of the main financial risk mitigation strategies that allows the minimization of potential financial exposures presented to IS project managers.
Hedging depends greatly on the correlation of the chosen assets. Correlation of the chosen assets depends on if the assets’ values increase or decrease together, signifying a positive correlation, or whether the assets’ values move in opposite directions, signifying a negative correlation. The correlation should be a negative correlation in order for the assets to be off setting of one another. Thus, the level of protection depends on the level of negative correlation the chosen assets possess.
However, the desired hedged negative correlation is often hard to achieve when trying to meet the goal-based financial plan and to meet the needed level of cyber security protection. The IS project manager needs to account for all of the identified risk factors, including those risk factors associated with protecting the companies most valuable asset, its data. However, there is often a difference between how efficiently a company can protect its data and how much of this desired protection the organization can afford. By not being able to protect everything from every threat, the IS project manager will need to keep in mind that it can’t financially protect the information system from all of the identified risk factors and possible threats, but he or she can focus on protecting the organization from risk factors and threats that would cause the most harm to an organization. Thus, in order to best attack the cyber security risk factors, the IS managers and their team needs to correctly analyze the risk factors, proving once again that the risk analysis stage is of utmost importance in the risk management process.
R
R
Technical Risk
Technical Risk
Technical risk is when a project fails due to its inability to align with technical standards. The information system design failed to satisfy the performance requirements of the goals the project was intended to fulfill. (Pinto) Technical risk resides on the formula ‘technical risk = uncertainty x Consequence of failure’ (Space), which is conducted during the probability and consequence and risk impact assessment phases of the Risk Analysis Stage. After finding the technical risk value, the technical risk is then categorized as a high, medium, or low risk factor during the Risk prioritization phase.
R
Technical Risk Assessment Process
The process of placing a high, medium, or low condition on a risk is referred to as the technical risk assessment process. (Space) After the sequential steps of the risk management process has been taken and there are materialized technical risks that are categorized as high, often a “tiger team of subject experts” is called in order to properly mitigate the high risk of not being able to technically perform and meet project goals. The formation of a super team of experts is the high technical risk mitigation strategy go to for most companies as long as the tradeoff of funding the “tiger team” and the resources needed is at an acceptable level.
R
Example of Technical Risk Failure:
A prime example of technical risk failure is the failure of the technical ability of the Obama Healthcare website being able to handle the magnitude of visitors on its servers. The specific technical risk that was not appropriately assessed was the data bandwidth capacity strength needed by the servers in order to process all of the user activity on the website. If the designers of the website had properly assessed this risk, a risk mitigation strategy could have been formulated and used to prevent the Obama Healthcare website server crash. Volz believes that the designers chosen for the website were not qualified for the task in the first place, dooming the project to technical risk from the beginning as he states, “the system for selecting private contractors that picked CGI Federal in the first place was the issue.”
R
In Depth Auto Sales Risk Analysis Example
The IS project manager will need to discuss with the Auto Sales management team on how the Auto Sales organization perceives risk. After interviewing the client management team, the IS Project Manager discovers that a high front- desk employee turn-over rate, resulting from financial risk failure and technical risk failure, is a threat capable of leading to an organizational risk of decreased sales. The threat of a high front-desk employee turn-over rate occurs due to the predisposing condition of having an overly complicated information system utilized by the front- desk employees. As a result, the front desk employees are either asked to resign due to underperformance or resign out of frustration.
As discussed already, financial risk failure results from the lack of proper investments made by management. Management of the Auto Sales team could have hedged investment assets. As for example, the front desk application software asset could have been hedged with an instructional learning software application to prevent a steep learning curve.
The steep learning curve is the result of technical risk failure. As previously discussed, technical risk failure is when a project fails due to its inability to align with technical standards. Thus, technical risk failure results from the misalignment of the information system with the front desk employee’s capabilities.
The organization will continue to be vulnerable unless the IS project team correctly analyzes this threat and assesses its potential adverse impact on sales, producing an organizational risk, as depicted by ‘image C’. An organizational risk is a risk that affects the organizations operations, assets, individuals, other organizations, and even the nation. (NIST Team)
(Image C)
R
R
Conclusion
The chosen risk mitigation strategy greatly depends on the risk type, the severity of the risk, and the cost to execute the chosen risk mitigation strategy. With properly measured negative correlations of resource assets, signifying the proper completion of the risk analysis stage, a company can adequately offset financial risk through hedging. A company can also target and minimize technical risk through utilizing the technical risk assessment process. This risk analysis technique will allow the formation of the proper team of experts to execute the high risk tasks and will also aid in aligning the information system with technical standards demanded. Thus, the proper risk mitigation greatly depends on the proper and thorough analysis of the risk inputs (predisposing risk conditions, vulnerabilities, threat sources, threat events, and adverse impacts) throughout the probability and Consequence Phase, Risk Impact Assessment Phase, and the Risk Prioritization Phase. If all else goes well then the control and documentation stage can occur.