SDLC Guide - Risk Management

SDLC Guide Risk Management
UNITED STATES MINT

Office of the Chief Information Officer (OCIO) DRAFT August 22, 2003
Version: Date:
Date mm/dd/yyyy
Version 1.0
Revision History Description Initial publication.
Custodian/Organization / OCIO
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 Internal risks - those that you can control; for example, project assumptions that may be invalid and organizational risks...............................................................................................15 External risks - events over which you have no direct control; for example, Government regulations and supplier performance....................................................................................15 Risk Evaluation .....................................................................................................................15 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.........................................15 No action You can take no action and accept responsibility if the risk event does occur..16 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
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
9/26/2013
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
9/26/2013
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 functional complexity interfaces to other applications dictated end dates or cost staff availability team commitment level team knowledge reliability of team members customer knowledge identified contract champion organizational impact related project experience customer participation customer proximity 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)? new product versus update/replacement project size dependency on other projects good information available staff turnover team size proximity of team members team morale reasonability of deadline stability of business area continued budget availability customer commitment level customer attitude agreeable customer acceptance process
You can also approach risk identification by looking at what could happendefine 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
9/26/2013
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 wont identify every possible risk, so its important to continue to identify risks on a regular basis throughout the projects 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.) List your projects 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 impactnegative or positivethat the risk would generate; that is, what there is to gain or lose
As you identify project risks, use the Excel spreadsheet on the following page to:
Risk Management
9/26/2013
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
9/26/2013
SDLC Guide Guide
Table 1. Risk Analysis

Risk Event Probability of Risk 1-very low to 5-very high Magnitude of Impact 1-very low to 5-very high Risk Triggers Mitigating Strategy Contingency Plan
Risk Management
9/26/2013
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 Short title of risk Keywords Risk statement Event probability Range of outcomes Expected timing Expected monetary value Performance measures
Purpose Quick reference for searching the database Terms to help in searching the database, and in categorizing and analyzing risks Complete sentence that clearly states the obstacle or undesired event The estimated likelihood of the risk occurring (for example, 10%) The anticipated effects of the risk occurring The range of dates within the project during which the risk would likely occur The cost of the risk, based on the probability and impact of that risk Triggers or thresholds for risk responses; that is, events that indicate a risk event may soon occur and that should generate a risk response Strategies and procedures for reducing, avoiding, or accepting the risk The individual responsible for developing the risk responses Strategies and procedures to follow if the risk occurs An indication of the current status of the risk: being watched, being
Response plan Responsible individual Contingency plan Risk status
Risk Management
9/26/2013
Data mitigated, or being retired History Action items
Purpose A record of events and decisions throughout the project 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 levelreducing the probability of occurrence, reducing the impact, or both. Be careful that the mitigating strategy you devise doesnt 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
9/26/2013
To tracking risk, you monitor risk indicators and mitigation actions; for example: Watching for the identified risk events and their triggers so youll 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 risks 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/26/2013
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
9/26/2013
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 estimateplus 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 9/26/2013
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 Dela
e ng ha nc .5
.8
.5 x .8 = .40
sig De
No d
elay .2
.5 x .2 = .10
No d
es ign .5 chan ge
y .1 Dela
.5 x .1 = .05
No d elay .9
.5 x .9 = .45 ----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 paththe longest path through the network, shown with red linesis 33 hours.
Risk Management
12
9/26/2013
8 hours Start 6 hours
2 hours 11 hours
3 hours 1 hour 11 hours End
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
9/26/2013
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 Identify the risks Analyze the risks Evaluate the risks Define risk aversion strategies
Before you can prepare a Risk Management Plan, you must:
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
Risk Management
14
9/26/2013
The capacity, documentation, familiarity, robustness, tool support, and usability of the methods, tools, and supporting equipment that will be used in the system development
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
Risk Management
15
9/26/2013
o No action You can take no action and accept responsibility if the risk event does occur 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
9/26/2013
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 1. Introduction 1.1 Project Description 1.2 Document Overview 1.3 For Additional Information or Changes 2. Assumptions, Constraints, and Preferences
Content Describe how you will implement risk management for the project. Provide the project name, project code, primary objectives, and customer. List and describe each section in the document, including appendixes. Explain who prepared the document, who will make changes, how to request changes, and who to contact for additional information. List the assumptions and constraints identified for each specific phase of the projects lifecycle.
Risk Management
17
9/26/2013
Section 3. Risk Management Approach 3.1 Risk Identification
Content Describe how you will identify and quantify risks, develop appropriate response strategies, and then monitor and control your strategies. Complete the first three columns of the Risk Listing Form (Category, WBS Number, and Threat/Opportunity Event) in Appendix C. Complete the next three columns of the Risk Listing Form (Probability, Impact, Overall Rating, and Priority Ranking) in Appendix C. For each risk that you identified in the Risk Listing Form, complete the Risk Response Strategies Form. Complete and maintain the Risk Management Plan Form and Risk Evaluation Form. Provide a glossary (in alphabetical order) of all terms and abbreviations used in the plan. List all references that you used to prepare this Risk Management Plan. List all threats and opportunities. Analyze all threats and opportunities. List all threat response strategies and threat response opportunities. Analyze all threat response strategies and threat response opportunities. List all threat management plans and opportunity management plans. Evaluate the effectiveness of all threat and opportunity strategies.
3.2 Risk Quantification (Risk Analysis and Prioritization) 3.3 Risk Response Development 3.4 Risk Response Control (Risk Monitoring and Control) A. Glossary B. Reference Documents C. Risk Listing Form D. Risk Analysis Form E. Risk Response Strategies Form F. Risk Response Development Form G. Risk Management Plan Form H. Risk Evaluation Form
Risk Management
18
9/26/2013

SDLC Guide - Risk Management

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SDLC Guide - Risk Management

Hochgeladen von

Copyright:

Verfügbare Formate

SDLC Guide Risk Management

UNITED STATES MINT