Risk Management

From CIO Wiki
Jump to: navigation, search

Risk management is the continuing process to identify, analyze, evaluate, and treat loss exposures and monitor risk control and financial resources to mitigate the adverse effects of loss.[1]

As the outcomes of business activities are uncertain, they are said to have some element of risk. These risks include strategic failures, operational failures, financial failures, market disruptions, environmental disasters, and regulatory violations. Risk is a statistical concept that is measured using statistical concepts that are related to the unknown future. Almost all investments are exposed to it. Risk management involves identifying the types of risk exposure within the company, measuring those potential risks, proposing means to hedge, insure or mitigate some of the risks and estimating the impact of various risks on the future earnings of the company. While it is impossible that companies remove all risk from the organisation, it is important that they properly understand and manage the risks that they are willing to accept in the context of the overall corporate strategy. The management of the company is primarily responsible for risk management, but the board of directors, internal auditor, external auditor, and general counsel also play critical roles. Risk can be managed in a number of ways: by the buying of insurance, by using derivative instruments as hedges, by sharing risks with others, or by avoiding risky positions altogether.[2]


Risk management’s objective is to assure uncertainty does not deflect the endeavor from the business goals. Risks can come from various sources including uncertainty in financial markets, threats from project failures (at any phase in design, development, production, or sustainment life-cycles), legal liabilities, credit risk, accidents, natural causes and disasters, deliberate attack from an adversary, or events of uncertain or unpredictable root-cause. There are two types of events i.e. negative events can be classified as risks while positive events are classified as opportunities. Several risk management standards have been developed including the Project Management Institute, the National Institute of Standards and Technology, actuarial societies, and ISO standards. Methods, definitions and goals vary widely according to whether the risk management method is in the context of project management, security, engineering, industrial processes, financial portfolios, actuarial assessments, or public health and safety. Strategies to manage threats (uncertainties with negative consequences) typically include avoiding the threat, reducing the negative effect or probability of the threat, transferring all or part of the threat to another party, and even retaining some or all of the potential or actual consequences of a particular threat, and the opposites for opportunities (uncertain future states with benefits). Certain aspects of many of the risk management standards have come under criticism for having no measurable improvement on risk; whereas the confidence in estimates and decisions seem to increase. For example, one study found that one in six IT projects were "black swans" with gigantic overruns (cost overruns averaged 200%, and schedule overruns 70%).[3]


Risk Management Example[4]
Proper risk management implies control of possible future events and is proactive rather than reactive. For example: An activity in a network requires that a new technology be developed. The schedule indicates six months for this activity, but the technical employees think that nine months is closer to the truth. If the project manager is proactive, the project team will develop a contingency plan right now. They will develop solutions to the problem of time before the project due date. However, if the project manager is reactive, then the team will do nothing until the problem actually occurs. The project will approach its six month deadline, many tasks will still be uncompleted and the project manager will react rapidly to the crisis, causing the team to lose valuable time. Proper risk management will reduce not only the likelihood of an event occurring, but also the magnitude of its impact. In the installation of an Interactive Voice Response system with a large telecommunications company, the coding department refused to estimate a total duration estimation for their portion of the project work of less than 3 weeks. An approach to the task duration estimation was that the lowest level task on a project whose total duration is 3 months or more should be no more than 5 days. So… this 3 week duration estimation was outside these boundaries. Nevertheless, the project team accepted it. It appeared an unrealistic timeline for the amount of work to be done but they were convinced that this would work. No risk assessment was conducted to determine what might go wrong. Unfortunately, this prevented their ability to successfully complete their tasks on time. When the 3 weeks deadline approached and it appeared that the work wouldn’t be completed, crisis management became the mode of operation.


Risk Management Standards[5]
A number of standards have been developed worldwide to help organisations implement risk management systematically and effectively. These standards seek to establish a common view on frameworks, processes and practice, and are generally set by recognised international standards bodies or by industry groups. Risk management is a fast-moving discipline and standards are regularly supplemented and updated. The different standards reflect the different motivations and technical focus of their developers, and are appropriate for different organisations and situations. Standards are normally voluntary, although adherence to a standard may be required by regulators or by contract, Commonly used standards include:

  • ISO 31000 2009 – Risk Management Principles and Guidelines
  • A Risk Management Standard – IRM/Alarm/AIRMIC 2002 – developed in 2002 by the UK’s 3 main risk organisations.
  • ISO/IEC 31010:2009 – Risk Management - Risk Assessment Techniques
  • COSO 2004 – Enterprise Risk Management - Integrated Framework
  • OCEG “Red Book” 2.0: 2009 – a Governance, Risk and Compliance Capability Model


Factors to Consider in Risk Management[6]
There are some specific factors to consider when examining project, product, and business risks. Some examples of these factors are listed here, although this list is meant to stimulate your thinking rather than to be an all-inclusive list.

  • People risks are associated with the availability, skill level, and retention of the people on the development team.
  • Size risks are associated with the magnitude of the product and the product team. Larger products are generally more complex with more interactions. Larger teams are harder to coordinate.
  • Process risks are related to whether the team uses a defined, appropriate software development process and to whether the team members actually follow the process.
  • Technology risks are derived from the software or hardware technologies that are being used as part of the system being developed. Using new or emerging or complex technology increases the overall risk.
  • Tools risks, similar to technology risks, relate to the use, availability, and reliability of support software used by the development team, such as development environments and other Computer-Aided Software Engineering (CASE) tools.
  • Organizational and managerial risks are derived from the environment where the software is being developed. Some examples are the financial stability of the company and threats of company reorganization and the potential of the resultant loss of support by management due to a change in focus or a change in people.
  • Customer risks are derived from changes to the customer requirements, customers’ lack of understanding of the impact of these changes, the process of managing these requirements changes, and the ability of the customer to communicate effectively with the team and to accurately convey the attributes of the desired product.
  • Estimation risks are derived from inaccuracies in estimating the resources and the time required to build the product properly.
  • Sales and support risks involve the chances that the team builds a product that the sales force does not understand how to sell or that is difficult to correct, adapt, or enhance.

Spontaneous and sporadic risk identification is usually not sufficient. There are various risk elicitation techniques the team can use to systematically and proactively surface risks:

  • Meeting. The team, including the development team and the marketing and customer representatives if possible, gathers together. The group brainstorms; each participant spontaneously contributes as many risks as they can possibly think of.
  • Checklists/Taxonomy. The risk elicitors are aided in their risk identification by the use of checklists and/or taxonomies (in other words, a defined, orderly classification of potential risks) that focuses on some subset of known and predictable risks. Checklists and taxonomies based upon past projects are especially beneficial. These artifacts should be used to interview project participants, such as the client, the developers, and the manager.
  • Comparison with past projects. The risk elicitors examine the risk management artifacts of previous projects. They consider whether these same risks are present in the new project.
  • Decomposition. Large, unwieldy, unmanageable risks that are identified are further broken down into small risks that are more likely to be managed. Additionally, by decomposing the development process into small pieces, you may be able to identify other potential problems.


Types of Risks (See Figure 1.)[7]
IT risk can involve a range of threats, from the everyday to the unthinkable, with varying levels of likelihood and impact. These threats can be grouped into three categories: Data-driven risks, business-driven risks and event-driven risks.

  • Data-driven risks: From an IT perspective, data-driven risks often receive the most attention. Generally, they occur more frequently than other types of risks, but the financial loss from any one occurrence is relatively low. These risks have some crossover with business-driven risk in terms of business continuity and business availability, but their focus is at the system or data level.
  • Business-driven risks: Business-driven risks directly impact business continuity and business operations. An organization’s board members would typically be most concerned about these risks because they are generally more strategic in nature than data-driven risks and have business wide ramifications.
  • Event-driven risks: Any event that disrupts an organization’s workforce, processes, applications, data or infrastructure can be classified as an event-driven risk. These risks affect business continuity and viability.


Types of Risks
Figure 1. source: IBM


Effectively Managing IT Risk requires

  • Evaluating how a disruption or corruption of IT services could threaten and impact critical business services
  • Effectively identifying and measuring IT risk to the business
  • Defining strategies for managing those risks judiciously
  • Defining and implementing an ongoing IT risk management and governance program
  • Monitoring IT risks on a continuous basis and taking appropriate, timely actions to mitigate the risk to business services


Requirements for Getting Risk Management Started[8]

  • Senior leadership commitment and participation is required.
  • Stakeholder commitment and participation is required.
  • Risk management is made a program-wide priority and "enforced" as such throughout the program's life-cycle.
  • Technical and program management disciplines are represented and engaged. Both program management and engineering specialties need to be communicating risk information and progress toward mitigation. Program management needs to identify contracting, funding concerns, SEs need to engage across the team and identify risks, costs, and potential ramifications, if the risk were to occur, as well as mitigation plans (actions to reduce the risk, and cost/resources needed to execute successfully).
  • Risk management integrated into the program's business processes and systems engineering plans. Examples include risk status included in management meetings and/or program reviews, risk mitigation plan actions tracked in schedules, and cost estimates reflective of risk exposure.


Risk Management Strategy[9]
These are the 5 risk management strategies that you can use to manage risk on your project. You’ll probably find yourself using a combination of techniques, choosing the strategies that best suit the risks on your project and the skills of your team. However you decide to approach risk, make sure that you log the action plan in your risk log and keep it up to date with the latest progress towards managing your risks.
1. Accept The Risk: Accepting the risk means that while you have identified it and logged it in your risk management software, you take no action. You simply accept that it might happen and decide to deal with it if it does. This is a good strategy to use for very small risks – risks that won’t have much of an impact on your project if they happen and could be easily dealt with if or when they arise. It could take a lot of time to put together an alternative risk management strategy or take action to deal with the risk, so it’s often a better use of your resources to do nothing for small risks.
2. Avoid The Risk: You can also change your plans completely to avoid the risk. This is a good strategy for when a risk has a potentially large impact on your project. For example, if January is when your company Finance team is busy doing the corporate accounts, putting them all through a training course in January to learn a new process isn’t going to be a great idea. There’s a risk that the accounts wouldn’t get done. It’s more likely, though, that there’s a big risk to their ability to use the new process, since they will all be too busy in January to attend the training or to take it in even if they do go along to the workshops. Instead, it would be better to avoid January for training completely. Change the project plan and schedule the training for February when the bulk of the accounting work is over.
3. Transfer The Risk: Transference is a risk management strategy that isn’t used very often and tends to be more common in projects where there are several parties. Essentially, you transfer the impact and management of the risk to someone else. For example, if you have a third party contracted to write your software code, you could transfer the risk that there will be errors in the code over to them. They will then be responsible for managing this risk, perhaps through additional training. Normally transference arrangements are written up into project contracts. Insurance is another good example. If you are transporting equipment as part of your project and the van is in an accident, the insurance company will be liable for providing new equipment to replace any that was damaged. The project team acknowledges that the accident might happen, but they won’t be responsible for dealing with sourcing replacement kit, moving it to the right location or paying for it as that is now the responsibility of the insurance company.
4. Mitigate The Risk: Mitigating against a risk is probably the most commonly mitigation of risk used risk management technique. It’s also the easiest to understand and the easiest to implement. What mitigation means is that you limit the impact of a risk, so that if it does occur, the problem it creates is smaller and easier to fix. For example, if you are launching a new washing machine and the Sales team then have to demonstrate it to customers, there is a risk that the Sales team don’t understand the product and can’t give good demonstrations. As a result, they will make fewer sales and there will be less revenue for the company. A mitigation strategy for this situation would be to provide good training to the Sales team. There could still be a chance that some team members don’t understand the product, or they miss the training session, or they just aren’t experts in washing machines and never will be, but the impact of the risk will be far reduced as the majority of the team will be able to demonstrate the new machine effectively. You can mitigate against the impact, like in this example, and you can also mitigate against the likelihood of it happening. Sometimes the actions will be broadly the same; sometimes you’ll have to have some tasks to reduce the chance that the risk happens and some separate tasks to make the impact of the risk smaller if it happens.
5. Exploit The Risk: Acceptance, avoidance, transference and mitigation are great to use when the risk has a negative impact on the project. But what if the risk has a positive impact? For example, the risk that the new washing machines are so popular that we don’t have enough Sales staff to do the demonstrations? That’s a positive risk – something that would have a benefit to the project and the company if it happened. In those cases, we want to maximize the chance that the risk happens, not stop it from happening or transfer the benefit to someone else!
Exploitation is the risk management strategy to use in these situations. Look for ways to make the risk happen or for ways to increase the impact if it does. We could train a few junior Sales admin people to also give washing machine demonstrations and do lots of extra marketing, so that the chance that there is lots of interest in the new machine is increased, and there are people to do the demos if needed.


Risk Management Cycle (See Figure 2.)[10]
The illustration below (Figure 2.) provides an example Risk Management Cycle that can be adopted and implemented by an institution after identifying and characterizing risks and determining its appropriate risk mitigation strategies.

  • Define Commitment to Risk Management: This is where the institution establishes its goals or desired outcomes for its risk management program. A goal or outcome, however, cannot be established until risks are identified and characterized. The commitment to risk management example could be a defined commitment for an IACUC to have no protocol related non-compliant items (NCIs) on USDA inspection reports. The commitment to no NCIs represents a Prevention strategy by the institution based on the identification and characterization of what could happen if there are NCIs on any given USDA inspection report. In other words, the institution deems the occurrence of protocol related NCIs on a USDA inspection report to carry such a serious impact that it determines that prevention is the best method for mitigating this risk.
  • Design Risk Management Framework: Designing a risk management framework means that the institution must be aware of all available actions, procedures, and/or processes, and potentially create some of their own. For the purposes of our example, an IACUC can look at a variety of methods to ensure that the protocols are well written, cover all aspects of the USDA Animal Welfare regulations, and are followed by compliant PIs. To continue with our example, we will say that the IACUC has chosen two methods for its risk management framework: protocol audits and focused pre-review of protocols describing animal research activities on USDA covered species.
  • Implement Framework: In this step, the institution must modify its operations to encompass the activities of the framework. Organizations or departments unused to creating new procedures or new programs may struggle with this step. Indeed, many risk programs fail because they are unable to operationalize what they said they wanted to do in order to mitigate risk. Such operationalization may include hiring new individuals, designing new jobs, reassigning work duties, creating new policies and procedures, training, changing documentation or electronic systems, and potentially creating an entirely new organizational culture. This can quickly become daunting and complex. The easiest way to approach this is to start with small changes that give you quick wins. You can build up on those easy and small successes with ever increasingly large changes until you arrive at your framework. Within our example, the audits of on-going protocols would need to be scheduled (after the auditing personnel are identified as well as trained and auditing procedures are codified) and pre-review initiated (again, after the same steps as to implement auditing).
  • Monitor Outcomes: Prior to initiating any changes and new activities, a reasonable timeframe for benchmarking success should be established. That timeframe allows for the new framework to be initiated, fully implemented, and undergo preliminary evaluation (in our example, this would be a USDA inspection). Outcomes (e.g. the USDA inspection report and additional feedback received at the time of the inspection) should then be thoroughly reviewed.
  • Improve Processes: Based on the review of the outcomes, modifications can be made to further improve outcomes and/or address shortcomings. To finish my example, this would be the time to review the USDA inspection report, assess the findings including if NCIs were included in the report, and determine if any changes need to be made to prevent the appearance of NCIs on future USDA inspection reports based on the reported NCIs and feedback.


Risk Management Cycle
Figure 2. source: ALN


What is important to remember about this Risk Management Cycle is that at any time the laws, regulations, guidelines, or other guidances may change. At that time, you have to re-enter the cycle by defining what your new commitment to risk management is based on the change. Commitments and strategies most certainly change when regulations and guidelines change, and institutions should not be too concerned about making a change. Making changes in accordance with regulatory changes can not only keep institutions up-to-date with current regulatory expectations but can also help to decrease self-imposed regulatory burden.


10 Key Ideas for Risk Management (See Figure 3.)
10 Key Ideas for Risk Management
Figure 3 source: NC State University


In the risk management cycle, product and project risks are identified, analyzed, and prioritized. The top-ranking risks are planned and mitigated. All risks are monitored. It is important for a project to focus on its critical success factors while keeping an eye on its risk factors. Risk management practices enable the team to find the opportunity in the risk items. Be proactive![11]


Principles of Risk Management[12]
There are specific core principles in regards to risk management. When looking to perform an actual risk assessment, the following target areas should be part of the overall risk management procedure (as defined by the International Standards Organization; ISO):

  • The process should create value
  • It should be an integral part of the organizational process
  • It should factor into the overall decision making process
  • It must explicitly address uncertainty
  • It should be systematic and structured
  • It should be based on the best available information
  • It should be tailored to the project
  • It must take into account human factors
  • It should be transparent and all-inclusive
  • It should be dynamic and adaptable to change
  • It should be continuously monitored and improved upon as the project moves forward


Risk Management Process(See Figure 4.)[13] The following diagram (Figure 3.) illustrates the six steps of the risk management process: identify, analyze and prioritize, plan and schedule, track and report, control, and learn. It is important to understand that the process of managing each risk goes through all of these steps at least once and often cycles through numerous times. Also, each risk has its own timeline, so multiple risks might be in each step at any point in time.


Risk Management Process
Figure 4. source: MicroSoft


  • Identify - Risk identification allows individuals to identify risks so that the operations staff becomes aware of potential problems. Not only should risk identification be undertaken as early as possible, but it also should be repeated frequently.
  • Analyze and prioritize - Risk analysis transforms the estimates or data about specific risks that developed during risk identification into a consistent form that can be used to make decisions around prioritization. Risk prioritization enables operations to commit resources to manage the most important risks.
  • Plan and schedule - Risk planning takes the information obtained from risk analysis and uses it to formulate strategies, plans, change requests, and actions. Risk scheduling ensures that these plans are approved and then incorporated into the standard day-to-day processes and infrastructure.
  • Track and report - Risk tracking monitors the status of specific risks and the progress in their respective action plans. Risk tracking also includes monitoring the probability, impact, exposure, and other measures of risk for changes that could alter priority or risk plans and ultimately the availability of the service. Risk reporting ensures that the operations staff, service manager, and other stakeholders are aware of the status of top risks and the plans to manage them.
  • Control - Risk control is the process of executing risk action plans and their associated status reporting. Risk control also includes initiating change control requests when changes in risk status or risk plans could affect the availability of the service or service level agreement (SLA).
  • Learn - Risk learning formalizes the lessons learned and uses tools to capture, categorize, and index that knowledge in a reusable form that can be shared with others.


The Risk Management Framework (See Figure 5.)[14]
Risk Management is the art and science of thinking about what could go wrong, and what should be done to mitigate those risks in a cost-effective manner. In order to identify risks and figure out how best to mitigate them, a framework is needed for classifying risks. All risks have two dimensions to them: likelihood of occurrence, and severity of the potential consequences. These two dimensions form four quadrants, which in turn suggest how we might attempt to mitigate those risks:


Risk Management Framework
Figure 5. source: Cayenne Consulting


Once we know the severity and likelihood of a given risk, we can answer the question: Does the benefit of mitigating a risk outweigh the cost of doing so?

  • Quadrant A: Ignorable Risks: Cost effectiveness is an important consideration in deciding how we face up to risks. Risks with relatively minor consequences and a relatively low likelihood of occurring – those in Quadrant A of our framework – obviously aren’t worth spending a lot of time worrying about. An example of a low-likelihood, minor-consequence risk might be the possibility of getting a flat tire on your way to a routine meeting. Assuming you service your car regularly and you drive on maintained roads, a flat tire might cause you to be late to a meeting once every ten years. It’s not a big deal.
  • Quadrant B: Nuisance Risks: The next category of risks are those we call “nuisance risks” – little things that often seem to go wrong, but whose impacts are easy enough to minimize through straightforward changes in behavior. There are countless examples of nuisance risks and simple solutions:
    • The printer runs out of toner while you’re preparing the proposal for the customer meeting that starts in 30 minutes. Solutions: don’t wait until the last minute, and always keep extra toner on hand.
    • Your lead engineer gets the flu three days before the scheduled release date of your first customer beta. Solutions: create a development process free of dependencies on any one person, and build in contingencies for the fact that almost everything seems to take twice as long and cost twice as much as you originally expect.
    • You knock a mug of coffee into your laptop keyboard and coat your hard drive in cream and sugar, making your marketing plan inaccessible. Solution: use software to perform automated daily backups so that you’ll lose, at most, a day of work if you destroy your computer.

With a little common sense, nuisance risks shouldn’t cause any lost sleep.

  • Quadrant C: Insurable Risks: Risks that could have major consequences but are relatively unlikely to happen are often insurable. Insurance is the practice of spreading the cost of an improbable loss across a group, so that no single individual bears the entire cost of a disaster. Everybody pays a premium to the insurance company, and the insurance company pays claim benefits when one of its customers experiences an insured loss. Here are a few common forms of insurance and the risks they cover:
    • Property & Casualty Insurance can mitigate losses from fire, theft, and natural disasters;
    • Key Executive Insurance can mitigate losses from the death or incapacitation of a management team member;
    • Liability Insurance can mitigate lawsuits resulting from product defects or on-site injuries to visitors;
    • Errors & Omissions Insurance can mitigate lawsuits from disgruntled customers; and
    • Directors & Officers Insurance can mitigate lawsuits in cases of negligence, harassment, or discrimination.

Even uncommon risks are often insurable. Some underwriters specialize in writing unusual policies: event cancellations due to adverse weather; or injury to specific body parts (early examples include Jimmy Durante, who insured his nose for $50,000, and Fred Astaire, who insured his legs for $75,000).

  • Quadrant D: The Company Killers: Now we come to the Company Killers: the risks with both a relatively high likelihood of occurrence and major consequences. These risks can sink startups and Fortune 500 companies alike. The survival of your venture depends on your ability to identify and mitigate the company killers. The thing that makes company killers so deadly is that there are so many of them. Individually, they may seem manageable, but collectively, they represent a true challenge for any entrepreneur. For example, suppose you manage to distill your world down to just ten company killers and you think you’ve eliminated 90% of the risk in each category:

There’s a 90% chance that you’ve identified a genuine market need;
There’s a 90% chance that your addressable market is as big as you think it is;
There’s a 90% chance that you can actually implement your innovation;
There’s a 90% chance that you can figure out how to sell it for more than it costs you to make it;
There’s a 90% chance that you have assembled the right management team to do the job;
There’s a 90% chance that you manage to stay one step ahead of the competition;
There’s a 90% chance that you don’t get sued into bankruptcy;
There’s a 90% chance that you won’t get buried in regulatory red tape;
There’s a 90% chance that you don’t run out of money; and
There’s a 90% chance that nothing else goes wrong.
You might take comfort in the fact that any one of these risk factors presents only a 10% chance of sinking the company. However, the probability of surviving all ten risk factors (making a technical assumption that the ten risk factors are statistically independent of each other) is:
90% × 90% × 90% × 90% × 90% × 90% × 90% × 90% × 90% × 90% = 35%
The key insight here is that a company that is reasonably good at managing individual risks might have a marginal chance of surviving overall. That’s why “reasonably good” isn’t good enough – risk management must be among the entrepreneur’s core competencies.


Reasons for Failure in Implementing Risk Management[15]
As time passes experience has been gained both nationally and internationally in respect of what functions and what does not function. Some of the elements that have had greatest negative impact are, in our opinion, the following:

  • Lack of clarity in vision and common values as well as badly formulated strategies and objectives which in turn lead to lack of co-operation and focus in the organisation.
  • Lack of a link between strategic objectives and risk management.
  • Imprecise mandate leading to lack of understanding of the role of the Risk Management function and the division of responsibilities.
  • The Head of Risk Management does not possess competency in risk management, strategy and the wider picture so that he/ she is not able to take on the role of advisor and challenger.
  • The Head of Risk Management does not understand the business.
  • The risk management concepts are not understood or are misunderstood.
  • Lack of ownership of the system tool used.
  • A tool is used without understanding its weaknesses and limitations.
  • Discussion is not encouraged, no effort is made to promote an honest and open evaluation of risk – “nobody should risk having their head cut off for telling it as it is”.
  • Lack of prioritization of significant risks.
  • Lack of understanding/ knowledge of correlation between risks.
  • Lack of management/ monitoring of IT risk.
  • Lack of focus on change in the risk profile and emerging risks.
  • The organisation is not convinced of the value of risk management efforts resulting in a lack of commitment.
  • The organisation and responsibility is unclear between the Head of Risk Management and the risk owners

.*Work performed by the various control functions is uncoordinated.

  • There is damaging competition/ professional rivalry between the Head of Risk Management and related functions e.g. Quality Management, Compliance and Internal Audit
  • Poorly performed risk evaluations lacking documentation of the underlying criteria for the evaluations so that Executive Management loses confidence in the accuracy of the risk profile presented.
  • Lack of quality assurance measures in respect of analyses/ evaluations.
  • Lack of a holistic view to reporting where differing formats for risk evaluations hinder aggregation at a higher level.


Risk Management Best Practices[16]

  • The taking of risk is a natural part of running any enterprise, but it is often not explicitly stated in the formulation of business decisions. The expression "risk" has often been exclusively associated with unwanted events, and risk management has been defined as analyzing and restricting the probability and impact of unwanted events. This is only one dimension of the total picture. Evaluating positive outcomes is just as important an element of ERM as evaluating the downside as ERM is concerned with the whole picture enterprise wide and evaluating risk strategy in relation to a portfolio of risks.
  • The objective of ERM is to maintain risk at an acceptable level and ensure the best balance possible between threats and opportunities — in line with the risk appetite and business strategy of the board and executive management. It is concerned with ensuring the achievement of goals as the enterprise develops and appropriate management of the organization's assets, including avoidance of losses as a result of unwanted events.
  • A prerequisite for being able to exercise sound risk management is therefore that there are clearly defined goals at the strategic level, to which goals at other levels in the organization may be linked. In this way risk evaluations at all levels will be linked to a hierarchy of objectives which supports the enterprise's overall strategy.
  • In practice this means ensuring the best possible basis for arriving at decisions at the various levels of the organization, so that the decisions made will support the overall objectives. Subsequently it is important to have a sound mechanism to ensure the achievement and monitoring of the decided activities.
  • Risk management may be defined as systematic, coordinated, and proactive activities aimed at the evaluation and treatment of uncertainty and events which can impact the achievement of goals. This includes amongst other things the organization's ability to:
    • Influence the probability and positive or negative impact of events.
    • Understand/exploit correlation between various types of risk.
    • Monitor development of the risk profile over time.
    • Initiate activities which align the path of development with the required direction.
    • Build a culture which ensures the implementation of activities and leads to sound risk management.
  • ERM means taking a holistic perspective, not just of the enterprise's status at a given moment, but also probable positive and negative developments in the future. In this way it becomes a tool for the balanced prioritization of resource utilization. For this reason, this work should also be harmonized with other management activities such as performance scorecards.
  • It is important that defined risk appetite can be translated into operational practice. There should be a common thread going through an organization's various objectives, management limits, authorities, and scope of action which accords with the total risk appetite and strategy. In those organizations where it is difficult to quantify risk appetite, it is especially important to devise suitable guiding principles delineating who as a decision maker can decide what should be the acceptable level of risk based on the relevant qualitative evaluations.
  • Risk management and decision making are interconnected. When making any major strategic decision, executive management should require a set of scenarios to be presented detailing impact and alternative actions, especially in the situation where there may be a high level of uncertainty.


Benefits of Risk Management[17]
The following are some of the specific benefits of a preventative risk management program:

  • See risks that are not apparent. Many of the real risks facing an organization cannot be gleaned from a textbook. A comprehensive preventative risk management program leverages a team of experts to identify and provide a deeper understanding of all types of risks.
  • Provide insights and support to the Board of Directors. Board members may find it difficult to identify risks outside their areas of expertise and experience. Providing resources and advisory services to the Board and its committees charged with risk management will make them better able to discharge their duties.
  • Get credit for cooperation. Many regulatory agencies have policies where they “give credit” to companies under investigation for having a compliance or a risk prevention program in place. While it is impossible to avoid risk and the manifestation of risk into potential problems, regulators want to see that an event is not due to a systemic breakdown and that the company has measures in place—such as proper leadership, training and certification—to prevent such activity.
  • Build a better defense to class-actions. Plaintiffs in class actions and other downstream litigation often rely on their ability to convince triers of fact that the defendants have been negligent. This is harder to prove when the company can point to a preventative risk mitigation program that is in place to minimize these risks.
  • Reduce business liability. Regulators and shareholders increasingly view litigation risk as a business liability. Reducing litigation risk upfront makes the company a more attractive investment.
  • Frame regulatory issues. Preventative risk management programs provide greater insight into insurance, indemnity and liability issues and allow the company to better focus and structure its inquiry.


Limitations to Risk Management[18]
Organizations must accept that Risk Management is not going to solve all issues. Once implemented correctly, Risk Management will improve various activities and prepare us for future uncertainties, but there are limitations to Risk Management Schemes.

  • Accidents occur no matter how much we prepare for them,
  • It will not defer all risk from the organisation,
  • It aids decision making, it doesn’t make decisions.


See Also

Key Risk Indicator (KRI)
Business Continuity
Business Continuity Planning (BCP)
Disaster Recovery Planning
Enterprise Risk Management (ERM)
Crisis Management


References

  1. Definition - What is Risk Management? marquette.edu
  2. Explaining Risk Management FT Lexicon
  3. Understanding Risk Management Wikipedia
  4. Risk Management Example bia.ca
  5. Risk Management Standards theirm.org
  6. Factors to Consider in Risk Management nscu.edu
  7. What are the Different Types of IT Risks and How can these IT Risks be Managed Effectively IBM
  8. Requirements for Getting Risk Management Started mitre.org
  9. Risk Management Strategy - 5 Ways to Manage Risk DBP Management
  10. Risk Management Cycle Stacy Pritt
  11. Keep an Eye on the Risk Factors ncsu.edu
  12. Principles of Risk Management Tom Tsongas
  13. Risk Management Process MicroSoft
  14. The Risk Management Framework Cayenne Consulting
  15. Reasons for Failure in Implementing Risk Management IIA Norge
  16. Risk Management Best Practices Norman Marks
  17. 6 Benefits of Risk Management Program osler.com
  18. Limitations to Risk Management Threats and Opportunities


External References