Risk Management
What is Risk Management
It is about understanding the internal and external influences that can cause project failure.
The main purpose is to identify and handle the uncommon causes of project variation.
The SEI definition of risk : “Risk is the possibility of suffering loss” (where loss is any negative impact to the project which could be in terms of time, costs, quality or outright project failure)
Risk is uncertainty or lack of complete knowledge of the set of all possible future events.
Strictly speaking, there are 2 main categories of risk:
Internal - which is within the control of a project manager
External - which is outside the control of a project manager
Classes of Risks
The Project manager deals with risks resulting from 3 general classes:
Known knowns - they are noted and described in the SPMP
Known unknowns - they are described in the RMP where they are prioritized and updated on a timely basis
Unknown unknowns - they are unknown, both as a category of risk and as a reality of the project (technical risks)
Risk Management concepts
Risk event: It is the precise description of what might happen to the project Risk probability: It is the degree to which the risk event is likely to occur Amount at stake: It is the loss incurred if the outcome is unsatisfactory Risk exposure: It is the overall liability potential of the risk; it is the product of Risk probability and loss
Concept and system exploration, along with requirements are the first three life cycle phases and are the phases in which project planning has the greatest impact on risk mitigation.
The inherent project risk is highest in these phases and drops through project execution.
Risk Management Models
Several models of risk management have been identified by the Project Management/Software Engineering institutes and through the ground-breaking work of Boehm. Project Management Institute’s Risk Model
PMI Risk Model As per the PMI model, project risk management is made up of:
Risk identification: Developing the sources of risk, identifying potential risk events, and symptoms of risk.
Risk quantification: using quantitative and qualitative analysis, determining the value of the opportunities to pursue verses the threats to avoid, and the opportunities to ignore verses the threats to accept.
Response planning: developing the risk management and contingency plans, identifying reserves required in both dollars and person-hours and determining how mitigation can occur through contractual means
Monitoring & Control: developing corrective action plans and monitoring their
implementation as part of the overall implementation of the risk management plan.
Boehm’s Risk Model
In this model, Risk management consists of 2 activities of risk assessment and control. Risk assessment is further divided into risk identification, analysis and prioritization.
Risk control consists of risk management planning, risk resolution, and risk monitoring. As with risk assessment, these 3 components are supported by sets of tools and techniques. Risk Assessment:
Risk identification is done by checklists, decision-driver analysis, and problem decomposition.
Risk Analysis is done through modeling performance and cost, and analyzing network, decision and quality factors.
Risk prioritization allows the project team to focus on those critical few risks that will have the greatest potential for causing project failure.
Boehm’s Risk Model
Risk management planning uses tools of buying information and risk avoidance, transfer, reduction, element planning and plan integration
Risk avoidance is simply finding a way to restructure the project and product to avoid that risk
Risk resolution is accomplished through prototypes, simulations, benchmarks, analyses and staffing.
Risk transfer usually involves the buying insurance against the occurrence of the risk. It is the actual transfer of responsibility for that part of the project with the inherent risk, to another organization.
Milestone tracking, top-ten risk tracking, risk reassessment, and corrective action provide the tools for risk monitoring.
These tools are all part of the steps that the project manager takes to implement complete risk management.
Boehm’s Risk Model
The SEI Model
This model provides information and feedback, internal and external to the project, on the risk activities, current risks, and emerging risks. The processes in this model include:
Identify - Search for and locate risks before they become problems
Analyze - transform risk data into decision-making information, evaluate impact, probability and timeframe; classify and prioritize risks
Plan - translate risk information into decisions and mitigating actions (both present and future) and implement those actions
Track - monitor risk indicators and mitigation actions
Control - correct for deviations from the risk mitigation plans Communication happens throughout all functions with some common process characteristics such as identification, analysis and quantification, response planning, tracking and communication.
Identifying Risks
This is accomplished by using the same tools as any analysis task.
Start out by having the team and the customer brainstorm possible risks to develop “known unknown” lists.
Use checklists of problems from prior projects retrieved from the project repository or knowledge-base.
Examine all project assumptions in the project plan for the slightest hint of risk. Pay special attention to those that assume a rosy future where everything works.
Interview stakeholders for risk identification and quantification.
Take the work breakdown structure and network diagrams from the PMP and look for precedence bottlenecks. These are the real choke points in the project planning network and have the highest risk reaction with schedule slips.
Identifying Risks
Sometimes flowcharting a process helps spot risky areas (especially if the process is not familiar)
Examine sources of key decisions in the project (decision-drivers).
There are different types of risks and the most important ones are:
Technical
Operational
Political
Legal
Regulatory
Market
Social
Internal
External
In general there are 3 basic risk areas - supportability, technical and programmatic.
The 3 basic risk areas
Technical tasks are a major part of software development business since software is the driver of high technology.
Programmatic sources arise from the process of trying to manage the software development project.
As the software project nears completion, the risks inherent in the software delivery, installation and maintainability are very real and obvious.
These 3 are the areas that add risk to cost and schedule. It should be kept in mind that cost and schedule are inherently risky.
Analyzing and Quantifying Risks
Brainstorming
Offer risk analysis ideas without judgement or evaluation
Build on ideas offered
Repeat until all ideas on risk analysis are exhausted
Delphi Method
Select a panel of experts (isolated and unknown)
Prepare and circulate a questionnaire about a risk
Solicit risk handling approaches and opinions
Share all responses and statistical feedback with entire group
Repeat until there is convergence on a consensus approach
Newer Methods
Sensitivity Analysis
Choose a few variables with big impact to the plan
Define a likely range of variation
Assess effect of changing them on project outcome
Analyzing and Quantifying Risks
Probability Analysis
Similar to sensitivity analysis
Adds a probability distribution for each variable.
Monte Carlo simulation
Similar to probability analysis
Assign randomly chosen values for each variable
Run simulation a number of times to get a probability distribution for the outcome
Produces a range of probabilities for the outcome
Utility Theory
Comprehends decision maker’s attitude towards risk
Viewed as theoretical
Decision Tree Analysis
Graphical Method
Forces probability considerations for each outcome
Usually applied to cost and time
Developing & Controlling Risks
Examples of key engineering development risks and treatments:
Unrealistic budget and schedule
Track all estimates and actuals; understand the teams’ performance level
Understand how all team members’ time is spent-there are always overhead activities in any organization
Don’t allow the client to talk you into an unrealistic estimate
Personnel shortfalls
Plan for training in areas needed for the project
Establish a learning pattern for team members throughout the project’s life
Cultivate teaming relationships with knowledgeable parties
Developing wrong capabilities
Insist on meeting with the customer
Prototype and demonstrate planned approaches
Risk Response The risk response development can handle identified tasks in 3 ways
Accept consequences in an active or passive fashion
Transfer or move the loss to a third party through a contract (warranty or insurance)
Mitigate or reduce the impact or probability of using contingency planning or a reserve, or eliminate the cause by using alternative software development strategies. Prepare appropriate responses by answering these questions:
Who is responsible for the action?
When is the action due?
What is the metric to watch?
What is the metric trigger value?
Risk Categories
1
Mission and Goals
2
Organization Management
3
Customer
4
Budget/Cost
5
Schedule
6
Project Content
7
Performance
8
Project Management
9
Development Process
10
Development Environment
11 Staff 12 Maintenance
Risk Management Plan
The Risk Management Plan will contain all the identified risks and mitigation plans where appropriate. It models the 12 categories of potential risk to any specific project.
1
Developing a risk management plan is a simple matter of 5 steps: Using the categories, construct a risk categorization table.
2 Rank the risk to the project for each category - Risk factors and areas, Low risk evidence (L), Medium risk evidence (M), High risk evidence (H), Rating, Comments. 3 Sort the risk table in order of risk with high-risk items first and calculate their risk exposure (key risks). Identify means to control them, establish ownership, and the date of completion. Integrate key risks into the project plan. Determine impact on schedule and cost. 4
Establish a regular risk report format for weekly project status meetings.