SDLC Guide - Risk Management

7/29/2019 SDLC Guide - Risk Management

1/21

SDLC GuideRisk Management

UNITED STATES MINTOffice of the Chief Information Officer (OCIO)

DRAFT August 22, 2003

Version:Date:


2/21

SDLC Guide Risk Management

Revision History

Date Version Description Custodian/Organization

mm/dd/yyyy 1.0 Initial publication. / OCIO


3/21


Table of Contents

Overview......................................................................................................................................1

The Risk Management Process................................................................................................2Identifying and Analyzing Risks...............................................................................................2Planning for Risk......................................................................................................................8Tracking Risk...........................................................................................................................8Controlling Risk........................................................................................................................9Communicating Risk..............................................................................................................10

Quantitative Risk Analysis......................................................................................................11Mean and mode.....................................................................................................................11

Standard deviation.................................................................................................................11Delphi technique....................................................................................................................11Mathematical expectation......................................................................................................12PERT/CPM.............................................................................................................................12Monte Carlo............................................................................................................................13

The Risk Management Plan.....................................................................................................14Risk Identification...................................................................................................................14Risk Analysis .........................................................................................................................15Internal risks - those that you can control; for example, project assumptions that may beinvalid and organizational risks...............................................................................................15

External risks - events over which you have no direct control; for example, Governmentregulations and supplier performance....................................................................................15Risk Evaluation .....................................................................................................................15Contingency planning You can plan contingencies in case the risk does occur, whichgives you a backup plan to minimize the affects of the risk event.........................................15No action You can take no action and accept responsibility if the risk event does occur..16Risk 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


4/21


Overview

Risk management is an approach to problem analysis that you can use to identify what can gowrong, quantify and access associated risks, and implement/control the appropriate approachfor 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 interdependentprojects

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 systemfailures and other disasters

User acceptance End users may not accept or use the solution, in part or as a whole

Risk Management 1 9/26/2013


5/21


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 emergingrisks

Identifying and Analyzing Risks

Risk is an undesirable situation or circumstance, which has both a probability of occurring anda potential consequence to project success. Risk has an impact on cost, schedule, andperformance.

Risk identification is the process of identifying uncertainty within all aspects of a project; inother words, what might go wrong and what happens if it does. For most information systemprojects, 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 andimpact. Lessons learned from previous projects may be a significant source for identifyingpotential risks on a new project.

In risk analysis, you quantify the identified risks and conduct detailed sensitivity studies of themost critical variables involved. The outcome of these analyses may be a quantified list ofprobabilities of occurrence and consequences that you can combine into a single numericalscore. This single score allows you to prioritize project risks.



6/21


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, alsoconsider inviting the managers one or two levels above the project manager to a separate riskanalysis meeting.) Encourage everyone to think creatively and speak freely, drawing on theirhistorical knowledge, judgment, and intuition. To get the creative juices flowing, here are somespecific 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 levelcustomer 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 afunctional solution rather than an elegant solution)?

You can also approach risk identification by looking at what could happendefine the causeand then determine the effect. However, you can also look at outcomes you want to encourageor avoid, and then look backward at what might cause each of those outcomes to occurdefine the effect and then determine the cause.



7/21


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, youwont identify every possible risk, so its important to continue to identify risks on a regularbasis 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 therisk event. For example, a risk event could be a delayed product release, and some rootcauses could be the loss of key team members, prolonged or catastrophic equipmentfailure, 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, youcould organize a sales process map around goals such as marketing, qualifying,proposing, and delivering, and under the marketing goal you could include activitiessuch as performing market research, conducting sales training, defining qualificationcriteria, 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 storyboardtakes the treatment (the overall mood and feel of the final product) and the roadmap ofevents, and combines them into a detailed description of the final product. (Refer toSDLC 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 productor program. The listing results from project engineering during the development andproduction of a material item. A WBS relates the elements of work to be accomplishedto each other and to the end product. (Refer to the information about Work BreakdownStructures in SDLC Guide Statement of Workfor detailed information.)

As you identify project risks, use the Excel spreadsheet on the following page to:

List your projects risk events; that is, occurrences that may affect the project in anegative orpositive 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



8/21


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 costestimates, and a missed milestone date may jeopardize future target dates)



9/21

SDLC GuideGuide

Table 1. Risk Analysis


Risk Event Probability

of Risk

Magnitude

of Impact

Risk Triggers Mitigating Strategy Contingency Plan

1-very low to

5-very high

1-very low to

5-very high


10/21


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 knowledgebase, which allows you consolidate and index relevant risk information. You could, forexample, 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 andanalyzing risks

Risk statement Complete sentence that clearly states the obstacle or undesiredevent

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 wouldlikely occur

Expected monetaryvalue

The cost of the risk, based on the probability and impact of that risk

Performance measures Triggers or thresholds for risk responses; that is, events thatindicate a risk event may soon occur and that should generate a

risk responseResponse 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



11/21


Data Purpose

mitigated, or being retired

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 areavailable, 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 anacceptable levelreducing the probability of occurrence, reducing the impact, or both. Becareful that the mitigating strategy you devise doesnt simply trade one risk for another. Alsobe sure that the cost of mitigation is reasonable given the probability and consequences of therisk.

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 mitigatingstrategy and one potential contingency plan.

Tracking Risk

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



12/21


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 theyoccur

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. Forexample, if a project design review shows inadequate progress in one area, the decision maybe made to change technical approaches or delay the project.

Controlling risk does not mean eliminating risk, but rather reducing, planning for, and resolvingrisk. That is, you can minimize risk or mitigate a risks effects by handling the unwantedoutcome 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 isreached. The most common techniques are inherent in good management and engineeringpractice:

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



13/21


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 thespreadsheet 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, andemerging 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 plannedstrategies to address the risk. Risk information then feeds the decision processes within theproject, and should establish support within external organizations for mitigation activities. Forexample, an agency comptroller who understands the project risks is more likely to allow theproject manager to have a management reserve within the project budget.

Communicating risk information in a clear, understandable, balanced, and useful manner isdifficult. The ability to state the problem at hand clearly, concisely, and without ambiguity isessential. Ensure that the mitigation activities conveyed include alternatives, objectively stated

justifications and trade off analyses. A well-planned and executed risk management programensures the decision maker receives unbiased information, resulting in the best projectdecisions.



14/21


Quantitative Risk Analysis

Risk is the measure of how significantly an actual outcome may vary from the plannedoutcome. 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. Forexample, 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 are9 years old).

Standard deviation

The standard deviation measures the variability of an estimateplus or minus compared to themean. 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) tomeasure 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 ofpaper.

2. Consolidate the results.

3. Ask each specialist whose estimate varies significantly from the mean to explain to thegroup the reasoning behind their estimate.

4. Repeat Steps 1 to 3 until all estimates are reasonably close.



15/21


Mathematical expectation

Mathematical expectation, which calculates the expected monetary value (EMV), is the productof two numbers: risk probability and risk value. Risk probability is the estimated probability thata specific risk event will occur. Risk value is the estimated value or impact of a gain or loss ifthe risk event occurs. Since EMV is only as accurate as the estimates you use in thecalculation, you should use mathematical evaluation in conjunction with the Delphi technique.

For complex situations that involve multiple alternatives, use a decision tree. Break down thesituation into components, calculate the EMV of each component, then determine the total costof following each branch of the tree. The figure below provides an example of a simpledecision tree for a proposed code change in a software application.

Desig

ncha

nge.5

Nodesignchange.5

Delay.8

Nodelay.2

.5 x .8 = .40

.5 x .2 = .10

Delay.1

Nodelay.9

.5 x .1 = .05

.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 reviewtechnique) and CPM (critical path method).

PERT allows you to determine how much time a project needs before it is completed. Youassign 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 leastamount of scheduling flexibility. You determine early dates by working forward from a specificstart 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 paththrough the network, shown with red linesis 33 hours.



16/21


Start

8

hours

6

hours

2

hours

11

hours

3

hours

11

hours

1 hour End

Figure 2. PERT/CPM chart

Monte Carlo

A simulation technique, Monte Carlo analysis allows you to quantify the risk associated withcost 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-basedsimulation. 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



17/21


The Risk Management Plan

Every project comes with inherent risks that could affect the success of the project asmeasured in terms of cost, schedule, and technical success. Risk management addressesissues that could endanger achievement of critical objectives, including internal and externalsources 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 mitigateadverse 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 IdentificationUsing a risk identification list to track risks is a critical facet of successful system developmentmanagement. You use the risk identification list from the beginning of the project, and it is amajor source of input for the risk assessment activity. Examples of categories that may be asource 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, andtraceability 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



18/21


The capacity, documentation, familiarity, robustness, tool support, and usability of the

methods, tools, and supporting equipment that will be used in the system developmentAfter 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 onthe 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 canunderstand the content and nature of the risk

Update the risk identification list throughout the life-cycle phases to ensure that all risks areproperly 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 asassigning numerical scores (1=low, 2=moderate, 3=high) to risk probability and severity ofimpact. The risk score for each risk is the product of the two scores. You then focus yourattention 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 willaccept, 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 ofexternal 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



19/21


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 riskare 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 ofrequirements or defining them more completely. For example, careful definition of thescope of a project in a SOW can avoid the possible consequence of "scope creep," orindecisive, protracted, and uncertain scope objectives.

Risk Aversion PlanFinally, identify and describe in detail the actions that you will take to transfer or mitigate risksthat you prioritized as high in the risk analysis. These actions should ultimately reduce projectrisk 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 projectactivities. You need to incorporate these activities into the budget, schedule, and other projectplan components. Also, refer to contingency plan documents for any contingency plans thathave been identified with the risk acceptance approach.

Use the risk aversion plan to direct all risk mitigation activities, and be sure to monitor andupdate the Risk Management Plan throughout the life-cycle phases.



20/21


Completing the Template

The following table provides more complete descriptions of the information you should providein 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, andcustomer.

1.2 Document Overview List and describe each section in the document, includingappendixes.

1.3 For AdditionalInformation or Changes

Explain who prepared the document, who will make changes,how to request changes, and who to contact for additionalinformation.

2. Assumptions,Constraints, andPreferences

List the assumptions and constraints identified for each specificphase of the projects lifecycle.



21/21


Section Content

3. Risk ManagementApproach

Describe how you will identify and quantify risks, developappropriate response strategies, and then monitor and controlyour 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(Risk Analysis andPrioritization)

Complete the next three columns of the Risk Listing Form(Probability, Impact, Overall Rating, and Priority Ranking) in

Appendix C.

3.3 Risk ResponseDevelopment

For each risk that you identified in the Risk Listing Form,complete the Risk Response Strategies Form.

3.4 Risk ResponseControl (Risk Monitoringand Control)

Complete and maintain the Risk Management Plan Form andRisk Evaluation Form.

A. Glossary Provide a glossary (in alphabetical order) of all terms andabbreviations used in the plan.

B. ReferenceDocuments

List all references that you used to prepare this Risk ManagementPlan.

C. Risk Listing Form List all threats and opportunities.

D. Risk Analysis Form Analyze all threats and opportunities.

E. Risk ResponseStrategies Form

List all threat response strategies and threat responseopportunities.

F. Risk ResponseDevelopment Form

Analyze all threat response strategies and threat responseopportunities.

G. Risk ManagementPlan Form

List all threat management plans and opportunity managementplans.

H. Risk Evaluation Form Evaluate the effectiveness of all threat and opportunity strategies.