SDLC Guide - Risk Management by keralaguest

VIEWS: 12 PAGES: 21

									        SDLC Guide
     Risk Management




          UNITED STATES MINT
Office of the Chief Information Officer (OCIO)
         DRAFT – August 22, 2003




                                        Version:
                                           Date:
                                      SDLC Guide – Risk Management



                                 Revision History
  Date       Version            Description         Custodian/Organization
mm/dd/yyyy     1.0     Initial publication.          / OCIO
                                                               SDLC Guide – Risk Management



                                                         Table of Contents

Overview................................................................................................................................... 1
The Risk Management Process .............................................................................................. 2
  Identifying and Analyzing Risks ............................................................................................. 2
  Planning for Risk .................................................................................................................... 8
  Tracking Risk ......................................................................................................................... 8
  Controlling Risk ...................................................................................................................... 9
  Communicating Risk ............................................................................................................ 10
Quantitative Risk Analysis .................................................................................................... 11
 Mean and mode ................................................................................................................... 11
 Standard deviation ............................................................................................................... 11
 Delphi technique .................................................................................................................. 11
 Mathematical expectation .................................................................................................... 12
 PERT/CPM .......................................................................................................................... 12
 Monte Carlo ......................................................................................................................... 13
The Risk Management Plan .................................................................................................. 14
  Risk Identification ................................................................................................................. 14
  Risk Analysis........................................................................................................................ 15
  Risk Evaluation .................................................................................................................... 15
  Risk Aversion Plan ............................................................................................................... 16
Completing the Template ...................................................................................................... 17



Tables and Figures
Table 1. Risk Analysis ............................................................................................................... 6
Table 2. Risk Knowledge Base .................................................................................................. 7
Table 3: Risk Management Plan Content ............................................................................... 17


Figure 1. Decision tree............................................................................................................. 12
Figure 2. PERT/CPM chart ...................................................................................................... 13
                                            SDLC Guide – Risk Management



Overview
Risk management is an approach to problem analysis that you can use to identify what can go
wrong, quantify and access associated risks, and implement/control the appropriate approach
for preventing or handling each risk identified.
In a software project, risks can include:
      Change management – Stakeholders may not accept the new system or their new role
      Compatibility – The product may not be compatible with future operating systems,
       software, or hardware
      Contract resources – The contractor may not be able to deliver the product, as defined,
       in the required time frame
      Financial – Funding limitations, budget overruns, performance incentives and
       disincentives, and missed milestones can affect project scope
      Interdependencies – Delays, resources, or budgets in the current project may affect
       other OEIS projects
      Legal/governmental – The project may not be completed in time to meet legal
       regulations, or may risk legal exposure
      Management commitment – Senior management and stakeholders may not be fully
       committed to the project
      Organizational – The project may affect to the organizational as a whole; for example,
       employee morale or lack of required new skills
      Schedule – The project requirements may force an unrealistic schedule, resulting in
       cost overruns, delayed benefits of implementation, and impacts to interdependent
       projects
      Staff resources – Required resources may not be available, may not have the needed
       skills, or may not stay in their current positions
      Strategic direction – The Department of the Treasury or the United States Mint may
       change their strategic direction, resulting in changing project requirements
      Technology – The hardware and software may not be able to perform under drastically
       changing conditions, and it may not be possible to adequately recover from total system
       failures and other disasters
      User acceptance – End users may not accept or use the solution, in part or as a whole




Risk Management                                1                                      12/7/2011
                                             SDLC Guide – Risk Management



The Risk Management Process
To effectively manage risk, you must:
      Identify – Recognize and define risks before they become problems
      Analyze – Translate risk information into decision-making information; evaluate the
       impact, probability, and timeframe for each risk; and classify and prioritize the risks
      Plan – Transform risk information into decisions and mitigating actions
      Track – Monitor the risks and mitigating actions
      Control – Correct for variances from the risk mitigation plan
      Communicate – Provide information on the risk activities, current risks, and emerging
       risks

Identifying and Analyzing Risks
Risk is an undesirable situation or circumstance, which has both a probability of occurring and
a potential consequence to project success. Risk has an impact on cost, schedule, and
performance.
Risk identification is the process of identifying uncertainty within all aspects of a project; in
other words, what might go wrong and what happens if it does. For most information system
projects, you can group these risks in the following categories:
      Technical. Risk associated with creating a new capability or capacity
      Supportability. Risk associated with implementing, operating, and maintaining a new
       capability
      Programmatic. Risk caused by events outside the project's control, such as public law
       changes
      Cost and Schedule. Risk that cost or schedule estimates are inaccurate or planned
       efficiencies are not realized
Project participants should continuously identify risks (at all levels), and the project
management team should capture these risks in definitive statements of probability and
impact. Lessons learned from previous projects may be a significant source for identifying
potential risks on a new project.
In risk analysis, you quantify the identified risks and conduct detailed sensitivity studies of the
most critical variables involved. The outcome of these analyses may be a quantified list of
probabilities of occurrence and consequences that you can combine into a single numerical
score. This single score allows you to prioritize project risks.



Risk Management                                   2                                       12/7/2011
                                            SDLC Guide – Risk Management



To identify and analyze risks, gather behind closed doors as early as possible in the project to
hold a facilitated, brainstorming-based risk assessment. Invite stakeholders, team members,
and infrastructure support staff. (To provide a different perspective on potential risks, also
consider inviting the managers one or two levels above the project manager to a separate risk
analysis meeting.) Encourage everyone to think creatively and speak freely, drawing on their
historical knowledge, judgment, and intuition. To get the creative juices flowing, here are some
specific potential risk areas you can discuss:
       new technology                        new product versus update/replacement
       functional complexity                 project size
       interfaces to other applications      dependency on other projects
       dictated end dates or cost            good information available
       staff availability                    staff turnover
       team commitment level                 team size
       team knowledge                        proximity of team members
       reliability of team members           team morale
       customer knowledge                    reasonability of deadline
       identified contract champion          stability of business area
       organizational impact                 continued budget availability
       related project experience            customer commitment level
       customer participation                customer attitude
       customer proximity                    agreeable customer acceptance process
You can also try posing these questions:
      What are the probabilities?
      What will the costs be if the problems do occur?
      What actions can we take to lower the probabilities, lessen the costs, or both?
      How do these actions fit in with the project schedule?
      What tradeoffs could help alleviate the risks, lessen the costs, or shorten the schedule
       (for example, delaying a piece of functionality until the next release, or settling for a
       functional solution rather than an elegant solution)?
You can also approach risk identification by looking at what could happen—define the cause
and then determine the effect. However, you can also look at outcomes you want to encourage
or avoid, and then look backward at what might cause each of those outcomes to occur—
define the effect and then determine the cause.

Risk Management                                 3                                        12/7/2011
                                             SDLC Guide – Risk Management



If you have provided a similar product or service many times before, there will be fewer risks
and they will be easier to identify. However, regardless of the number of risks you identify, you
won’t identify every possible risk, so it’s important to continue to identify risks on a regular
basis throughout the project’s lifecycle.
You can also use a variety of charting techniques to identify risks.
      Fishbone/Ishikawa diagram – A cause-and-effect diagram shaped like a fish skeleton,
       where the head represents the risk event, and the ribs identify the root causes of the
       risk event. For example, a risk event could be a delayed product release, and some root
       causes could be the loss of key team members, prolonged or catastrophic equipment
       failure, or improper requirements definition.
      Flowchart – Helps you define and visualize processes, and can help you understand
       the causes and effects of risks. (Refer to SDLC Guide - Charts for detailed information.)
      Process map –Documents the flow of a process from inputs to outputs, which provides
       a focal point from which to analyze opportunities for improvement. For example, you
       could organize a sales process map around goals such as marketing, qualifying,
       proposing, and delivering, and under the marketing goal you could include activities
       such as performing market research, conducting sales training, defining qualification
       criteria, and generating suspects.
      Storyboard – Allows more detailed illustration of the contents of each element, as
       opposed to a flowchart, which focuses on movement through a system. The storyboard
       takes the treatment (the overall mood and feel of the final product) and the roadmap of
       events, and combines them into a detailed description of the final product. (Refer to
       SDLC Guide - Charts for detailed information.)
      Work breakdown structure – A product-oriented listing, in family tree order, of the
       hardware, software, services, and other work tasks, which completely defines a product
       or program. The listing results from project engineering during the development and
       production of a material item. A WBS relates the elements of work to be accomplished
       to each other and to the end product. (Refer to the information about Work Breakdown
       Structures in SDLC Guide – Statement of Work for detailed information.)
As you identify project risks, use the Excel spreadsheet on the following page to:
      List your project’s risk events; that is, occurrences that may affect the project in a
       negative or positive way
      Based on historical data and available research, estimate the probability of the risk
       occurring
      Estimate the potential impact—negative or positive—that the risk would generate; that
       is, what there is to gain or lose



Risk Management                                  4                                        12/7/2011
                                            SDLC Guide – Risk Management



     Identify one or more triggers for each risk event; that is, things that let you know a risk
      event will likely occur (for example, cost overruns may point to inadequate cost
      estimates, and a missed milestone date may jeopardize future target dates)




Risk Management                                 5                                        12/7/2011
                                                                                                SDLC Guide Guide


Table 1. Risk Analysis

           Risk Event    Probability of    Magnitude      Risk Triggers   Mitigating Strategy       Contingency Plan
                              Risk         of Impact
                          1-very low to   1-very low to
                           5-very high     5-very high




Risk Management                                               6                                                 12/7/2011
                                               SDLC Guide – Risk Management



After completing your initial risk analysis, use the qualitative risk probability classifications (very
high, low, and so on) to:
      Prioritize the risks
      Determine which levels of risk require additional analysis and, potentially, risk
       management actions
      Group risks; for example, by the urgency level (those that need immediate attention and
       those that can wait), or by affected area (such as schedule, cost, quality, and so on)
After completing your initial risk analysis, you can also capture the information in a knowledge
base, which allows you consolidate and index relevant risk information. You could, for
example, include knowledge database fields such as those shown in the figure below.


Table 2. Risk Knowledge Base

           Data                                              Purpose
Short title of risk            Quick reference for searching the database
Keywords                       Terms to help in searching the database, and in categorizing and
                               analyzing risks
Risk statement                 Complete sentence that clearly states the obstacle or undesired
                               event
Event probability              The estimated likelihood of the risk occurring (for example, 10%)
Range of outcomes              The anticipated effects of the risk occurring
Expected timing                The range of dates within the project during which the risk would
                               likely occur
Expected monetary              The cost of the risk, based on the probability and impact of that risk
value
Performance measures           Triggers or thresholds for risk responses; that is, events that
                               indicate a risk event may soon occur and that should generate a
                               risk response
Response plan                  Strategies and procedures for reducing, avoiding, or accepting the
                               risk
Responsible individual         The individual responsible for developing the risk responses
Contingency plan               Strategies and procedures to follow if the risk occurs
Risk status                    An indication of the current status of the risk: being watched, being
                               mitigated, or being retired

Risk Management                                    7                                        12/7/2011
                                            SDLC Guide – Risk Management



          Data                                            Purpose
History                     A record of events and decisions throughout the project
Action items                A record of specific actions (including assigned resource, due date,
                            and completion status) throughout the project



Planning for Risk
Risk planning decides what to do about a project risk. It involves taking the risk information you
have gathered, and transforming it into decisions, mitigating strategies, and contingency plans.
Available decision actions are:
      Avoid the risk
      Control the risk
      Assume the risk
      Transfer the risk
The action you select for each risk will depend on the project phase, the options that are
available, and the resources that you can use for risk management. A majority of project
activities involve tracking and controlling the project risk.
A mitigating strategy is a plan to reduce the impact or magnitude of a risk event to an
acceptable level—reducing the probability of occurrence, reducing the impact, or both. Be
careful that the mitigating strategy you devise doesn’t simply trade one risk for another. Also
be sure that the cost of mitigation is reasonable given the probability and consequences of the
risk.
A contingency plan defines the actions you will take if the risk event actually occurs.
Again using the spreadsheet in Table 1, for each identified risk, develop at least one mitigating
strategy and one potential contingency plan.

Tracking Risk
Risk tracking involves gathering and analyzing project information that measures risk. For
example, test reports, design reviews, and configuration audits are risk tracking tools that
project managers can use to assess the technical risk of moving forward into the next life cycle
phase.




Risk Management                                 8                                         12/7/2011
                                            SDLC Guide – Risk Management



To tracking risk, you monitor risk indicators and mitigation actions; for example:
      Watching for the identified risk events and their triggers so you’ll know if/when they
       occur
      For the risk events that have occurred, controlling the impact of the events, enacting
       contingency plans, and tracking the contingency plans’ associated risks
      Identifying new or previously unidentified risks
      Ensuring that the risk plans are enacted and effective

Controlling Risk
Risk control takes the results of risk tracking and decides what to do and then does it. For
example, if a project design review shows inadequate progress in one area, the decision may
be made to change technical approaches or delay the project.
Controlling risk does not mean eliminating risk, but rather reducing, planning for, and resolving
risk. That is, you can minimize risk or mitigate a risk’s effects by handling the unwanted
outcome in an acceptable way.
Strategies for controlling risk include:
      Avoiding the risk by changing performance or functionality requirements
      Transferring the risk by allocating those risks to other systems
      Assuming the risk by accepting and controlling it
You can use risk mitigation techniques to control or transfer risk until an acceptable risk level is
reached. The most common techniques are inherent in good management and engineering
practice:
      Budget management reserve - mitigates cost risk
      Schedule slack - mitigates schedule risk
      Parallel development - mitigates technical risk
      Prototyping - mitigates technical risk
      Incentive fee and incentive-firm contract types - mitigates cost risk
      Entrance and exit criteria for major design reviews - mitigates cost, schedule and
       technical risks




Risk Management                                  9                                       12/7/2011
                                            SDLC Guide – Risk Management



You should also create a risk management database to help you track actions on this project
and act as a repository of ―lessons learned.‖ In addition to the information included in the
spreadsheet in Table 1, be sure to include:
      The name of the risk owner (every risk response should have an owner)
      Whether the risk event occurred
      Whether the risk mitigation strategy was effective
      Whether the contingency plan was effective

Communicating Risk
Communicating risk involves providing information on risk activities, current risks, and
emerging risks to both team members and stakeholders.
You should make risk an agenda item at all project team meetings. Take time to:
      Review the status of all identified risks and mitigations
      Determine whether additional mitigations are both required and reasonable
      Gauge the need for enacting contingency plans
      Identify and discuss all possible new risks
Communicate risk information to all levels of the project organization and to appropriate
external organizations. This ensures understanding of the project risks and the planned
strategies to address the risk. Risk information then feeds the decision processes within the
project, and should establish support within external organizations for mitigation activities. For
example, an agency comptroller who understands the project risks is more likely to allow the
project manager to have a management reserve within the project budget.
Communicating risk information in a clear, understandable, balanced, and useful manner is
difficult. The ability to state the problem at hand clearly, concisely, and without ambiguity is
essential. Ensure that the mitigation activities conveyed include alternatives, objectively stated
justifications and trade off analyses. A well-planned and executed risk management program
ensures the decision maker receives unbiased information, resulting in the best project
decisions.




Risk Management                                 10                                       12/7/2011
                                            SDLC Guide – Risk Management



Quantitative Risk Analysis
Risk is the measure of how significantly an actual outcome may vary from the planned
outcome. To determine levels of risk, you need: effective measurements that are valid, reliable,
and accurate; and tools and techniques to analyze the measurements.
Some of the more common quantitative tools and techniques are:
      Mean
      Mode
      Standard deviation
      Delphi technique
      Mathematical expectation
      PERT/CPM
      Monte Carlo
The sections that follow describe each of these tools and techniques in more detail.

Mean and mode
The mean is simply the average, and the mode is the value that occurs most frequently. For
example, if a family has five children and their ages are 15, 13, 9, 9, and 4, the mean is 10 (the
sum of the ages, 50, divided by the number of children, 5) and the mode is 9 (two children are
9 years old).

Standard deviation
The standard deviation measures the variability of an estimate—plus or minus compared to the
mean. The greater the standard deviation, the greater the risk of the estimate.

Delphi technique
Without quantitative data, you can use the Delphi technique (also called ―expert judgment‖) to
measure risk. This technique involves four steps:
   1. Ask a group of specialists to estimate a value for a risk event., and write it on a piece of
      paper.
   2. Consolidate the results.
   3. Ask each specialist whose estimate varies significantly from the mean to explain to the
      group the reasoning behind their estimate.
   4. Repeat Steps 1 to 3 until all estimates are reasonably close.


Risk Management                                11                                       12/7/2011
                                                        SDLC Guide – Risk Management



Mathematical expectation
Mathematical expectation, which calculates the expected monetary value (EMV), is the product
of two numbers: risk probability and risk value. Risk probability is the estimated probability that
a specific risk event will occur. Risk value is the estimated value or impact of a gain or loss if
the risk event occurs. Since EMV is only as accurate as the estimates you use in the
calculation, you should use mathematical evaluation in conjunction with the Delphi technique.
For complex situations that involve multiple alternatives, use a decision tree. Break down the
situation into components, calculate the EMV of each component, then determine the total cost
of following each ―branch‖ of the tree. The figure below provides an example of a simple
decision tree for a proposed code change in a software application.



                                                                 y   .8   .5 x .8 = .40
                                                            Dela
                                                   .5
                                              ge
                                            an            No d
                                      n   ch                   elay
                                                                    .2    .5 x .2 = .10
                                  sig
                             De

                            No
                               d   es                                     .5 x .1 = .05
                                     ign                        y   .1
                                    .5 chan                Dela
                                            ge
                                                          No d            .5 x .9 = .45
                                                               elay
                                                                    .9             -----
                                                                                   1.00

                     Figure 1. Decision tree




PERT/CPM
To control schedules and lead times, you can use PERT (program evaluation and review
technique) and CPM (critical path method).
PERT allows you to determine how much time a project needs before it is completed. You
assign a best, worst, and most probable completion time estimate to each activity, then use
these estimates to determine the average completion time.
CPM allows you to predict project duration by analyzing which set of activities has the least
amount of scheduling flexibility. You determine early dates by working forward from a specific
start date, and you determine late dates by working backward from a specific completion date.
The figure below presents a PERT/CPM chart in which the critical path—the longest path
through the network, shown with red lines—is 33 hours.



Risk Management                                          12                                12/7/2011
                                                      SDLC Guide – Risk Management



                                8               2                3
                              hours           hours            hours

                                                        11
                     Start                                             1 hour   End
                                                       hours

                                        6                       11
                                      hours                    hours

                     Figure 2. PERT/CPM chart




Monte Carlo
A simulation technique, Monte Carlo analysis allows you to quantify the risk associated with
cost and schedule scenarios. Many statistical software packages include Monte Carlo analysis,
and several are available as plug-ins to spreadsheet applications.
Although decision trees are valuable for complex situations that involve multiple alternatives,
situations with highly complex mathematical calculations are better suited to computer-based
simulation. Computer-based simulation offers several additional benefits:
      The random number generation functionality allows you to run hundreds or even
       thousands of simulations to increase the accuracy of your estimate
      You can adjust the probability for critical-path activities, allowing you to evaluate
       contingency plans, cost assumptions, estimates, and so on




Risk Management                                        13                                 12/7/2011
                                               SDLC Guide – Risk Management



The Risk Management Plan
Every project comes with inherent risks that could affect the success of the project as
measured in terms of cost, schedule, and technical success. Risk management addresses
issues that could endanger achievement of critical objectives, including internal and external
sources for cost, schedule, and technical risks on a project.
The Risk Management Plan:
      Identifies potential problems before they occur
      Addresses issues that could endanger achievement of critical objectives, including
       internal and external sources for cost, schedule, and technical risks
      Defines risk-aversion activities that can be implemented as needed to avoid or mitigate
       adverse impacts on achieving objectives
Before you can prepare a Risk Management Plan, you must:
      Identify the risks
      Analyze the risks
      Evaluate the risks
      Define risk aversion strategies

Risk Identification
Using a risk identification list to track risks is a critical facet of successful system development
management. You use the risk identification list from the beginning of the project, and it is a
major source of input for the risk assessment activity. Examples of categories that may be a
source of risk for a system development project are:
      The complexity, difficulty, feasibility, novelty, verifiability, and volatility of the system
       requirements
      The correctness, integrity, maintainability, performance, reliability, security, testability,
       and usability of the SDLC deliverables
      The developmental model, formality, manageability, measurability, quality, and
       traceability of the processes used to satisfy the customer requirements
      The communication, cooperation, domain knowledge, experience, technical knowledge,
       and training of the personnel associated with technical and support work on the project
      The budget, external constraints, politics, resources, and schedule of the external
       system environment
      The capacity, documentation, familiarity, robustness, tool support, and usability of the
       methods, tools, and supporting equipment that will be used in the system development

Risk Management                                    14                                         12/7/2011
                                              SDLC Guide – Risk Management



After you identify the risks, document them in a risk identification list:
   1. Number each risk using sequential numbers or other identifiers
   2. Identify the SDLC document to which the risk applies; for example, if you are working on
      the CM Plan and discover a CM risk, identify the CM Plan as the related document.
   3. Describe the risk in enough detail that a third party who is unfamiliar with the project can
      understand the content and nature of the risk
Update the risk identification list throughout the life-cycle phases to ensure that all risks are
properly documented.

Risk Analysis
Analyze the risks you have identified:
   1. Categorize the risks as:
         o Internal risks - those that you can control; for example, project assumptions that
            may be invalid and organizational risks
         o External risks - events over which you have no direct control; for example,
            Government regulations and supplier performance.
   2. Evaluate each identified risk item in terms of probability and impact, determine the
      probability that the risk will occur, and determine the resulting impact if it does occur
Use an evaluation tool to score each risk; for example, you can use a simple model such as
assigning numerical scores (1=low, 2=moderate, 3=high) to risk probability and severity of
impact. The risk score for each risk is the product of the two scores. You then focus your
attention on those risks with a score of 9 (high risk probability and high severity of impact),
followed by 6, and so on.

Risk Evaluation
Review the risk items with high rankings from the risk analysis and determine whether you will
accept, transfer, or mitigate the significant risks.
      Accept the risks – With the acceptance approach, you do not make any effort to avoid
       the risk item. You usually employ this approach when the risk items are the result of
       external factors over which you have no direct control. In the acceptance approach,
       there are two types of action you can take:
          o Contingency planning – You can plan contingencies in case the risk does occur,
               which gives you a backup plan to minimize the affects of the risk event
          o No action – You can take no action and accept responsibility if the risk event
               does occur



Risk Management                                   15                                      12/7/2011
                                              SDLC Guide – Risk Management



      Transfer the risks – With the transfer approach, the objective is to reduce risk by
       transferring it to another entity that can better bear it. Two methods of transferring risk
       are the use of insurance and the alignment of responsibility and authority.
      Mitigate the risks – With the mitigation approach, emphasis is on actually avoiding,
       preventing, or reducing the risk. You can avoid some risks by reducing the number of
       requirements or defining them more completely. For example, careful definition of the
       scope of a project in a SOW can avoid the possible consequence of "scope creep," or
       indecisive, protracted, and uncertain scope objectives.

Risk Aversion Plan
Finally, identify and describe in detail the actions that you will take to transfer or mitigate risks
that you prioritized as high in the risk analysis. These actions should ultimately reduce project
risk and should directly affect the project plan and the project metrics.
Activities to reduce the effects of risk require effort, resources, and time, just like other project
activities. You need to incorporate these activities into the budget, schedule, and other project
plan components. Also, refer to contingency plan documents for any contingency plans that
have been identified with the risk acceptance approach.
Use the risk aversion plan to direct all risk mitigation activities, and be sure to monitor and
update the Risk Management Plan throughout the life-cycle phases.




Risk Management                                   16                                       12/7/2011
                                          SDLC Guide – Risk Management



Completing the Template
The following table provides more complete descriptions of the information you should provide
in the Risk Management Plan.


Table 3: Risk Management Plan Content

         Section                                         Content
 1. Introduction            Describe how you will implement risk management for the
                            project.
 1.1 Project Description    Provide the project name, project code, primary objectives, and
                            customer.
 1.2 Document Overview      List and describe each section in the document, including
                            appendixes.
 1.3 For Additional         Explain who prepared the document, who will make changes,
 Information or Changes     how to request changes, and who to contact for additional
                            information.
 2. Assumptions,            List the assumptions and constraints identified for each specific
 Constraints, and           phase of the project’s lifecycle.
 Preferences




Risk Management                               17                                      12/7/2011
                                          SDLC Guide – Risk Management



         Section                                         Content
3. Risk Management         Describe how you will identify and quantify risks, develop
Approach                   appropriate response strategies, and then monitor and control
                           your strategies.
3.1 Risk Identification    Complete the first three columns of the Risk Listing Form
                           (Category, WBS Number, and Threat/Opportunity Event) in
                           Appendix C.
3.2 Risk Quantification    Complete the next three columns of the Risk Listing Form
(Risk Analysis and         (Probability, Impact, Overall Rating, and Priority Ranking) in
Prioritization)            Appendix C.
3.3 Risk Response          For each risk that you identified in the Risk Listing Form,
Development                complete the Risk Response Strategies Form.
3.4 Risk Response          Complete and maintain the Risk Management Plan Form and
Control (Risk Monitoring   Risk Evaluation Form.
and Control)
A. Glossary                Provide a glossary (in alphabetical order) of all terms and
                           abbreviations used in the plan.
B. Reference               List all references that you used to prepare this Risk
Documents                  Management Plan.
C. Risk Listing Form       List all threats and opportunities.
D. Risk Analysis Form      Analyze all threats and opportunities.
E. Risk Response           List all threat response strategies and threat response
Strategies Form            opportunities.
F. Risk Response           Analyze all threat response strategies and threat response
Development Form           opportunities.
G. Risk Management         List all threat management plans and opportunity management
Plan Form                  plans.
H. Risk Evaluation Form    Evaluate the effectiveness of all threat and opportunity strategies.




Risk Management                               18                                         12/7/2011

								
To top