Risk mgmt

IBM Global Services (ITS)
10/30/15 © 2004 IBM Corporation
Risk Management Fundamentals
and Beyond
Dr. Oliver Klapp

© 2004 IBM Corporation
2 Risk Management Fundamentals 10/30/15
Agenda
1
2
3
4
What is Risk Management?
Why is Risk Management Important?
Risk Categories: Risk Management Planning VITPM 4.12
Risk Categories: Risk Identification VITPM4.13
5 Risk Categories: Qualitative Risk Analysis
Risk Categories: Quantitative Risk Analysis
Recommendations and Summary
Risk Categories: Risk Response Planning VITPM 4.15
Risk Categories: Risk Monitoring and Control VITPM 6.6
6
7
8
9
VITPM 4.14

Agenda
1
2
3
4
Risk Categories: Risk Management Planning
Risk Categories: Risk Identification
Risk Categories: Risk Response Planning
Risk Categories: Risk Monitoring and Control
6
7
8
9

 Risk Management is the systematic process of identifying,
analyzing and responding to project risk. (PMBOK Guide)
 It includes [maximizing the probability and consequences of
positive events and] minimizing the probability and consequences
of adverse events to project objectives.

 IBM defines Risk as 'a possible undesirable and unplanned event that
could result in the project not meeting one or more of its objectives'
 PMI further defines risk as involving only the possibility of suffering harm
or loss. (PMBOK)
 Synonyms for risk include danger, jeopardy, hazard, peril, gamble, chance
(MS Word Thesaurus)
deutsch: Gefahr, Gefährlichkeit, Wagnis, Glücksfall, Unsicherheit, …
 Thus, Risk Management can be defined as ‘the art and science of
identifying, analysing and responding to risk events.' (PMBOK)
Risk Management Definitions

Impact
Probability
Low
Impact
High Impact
Low Probability
High
Probability
Low Risk
Moderate
Risk
High Risk
An Event
A risk event is defined as a
possible undesirable event
or unplanned opportunity.
All projects have risks. If
risks are ignored you will
increase the likelihood that
the project will fail, or will
be less successful.
What is Risk

Risk versus Issues
 Risks is when an event may occur
– Risk management allows for proactive management
– It allows customer expectation management early
– Financial impacts may be avoided
 Issue is when a risk has eventuated (a fact, e.g. PMRs)
– Reactive management approach
– Issue results in loss – financial or customer satisfaction

Risk vs. Change vs. Issue Management
 Risks Management
– A strategic process for identifying and managing possible future
events that may influence project performance and results
 Change Management
– A process to formally control the management and approval of
project baselines (requirements, technical, schedule and so on) and
changes to those baselines
 Issue Management
– A tactical process to formally control the management of problems
that typically result from risk, change, ineffective project
management, or a combination of these

Agenda
1
2
3
4
6
7
8
9

Why is Risk Management Important, Why Focus on Risk
Management?
 Through managing uncertainty, effective risk management:*
– Protect:
• Spend (GP), cost
• Schedule
• Requirements
– Prevent surprises
– Prevent management by crisis
– Prevent problems from occurring or, if they do occur, from escalating
– by organizational appreciation of uncertainty, increases
competitiveness in bidding and reduces chance of disaster
contracts/projects (can you think of any?) where risk is too great.
– helps build good employee morale by encouraging creative thinking,
cross team communication and trust.
– And much more!
*Chapman, Chris and Steve Ward (1996). Why You Need Risk Management. Project Management
Requirements
Cost Schedule

Project risk and consequences vary over the project life cycle
Risk
Time
Total Project Life Cycle
Conceive Develop Implement Terminate
Amount of Stake
Opportunity and Risk
Period of
Highest Risk
Impact
$ Value

Risk Management Planning
Approach on how to manage risks in the project
Risk Identification
Determining the risks that may affect the project and documenting
characteristics (consider validity of assumptions)
Qualitative Risk Analysis
Qualitative Analysis and prioritising its effects
Quantitative Risk Analysis
Measuring the probability of impact
Estimating the cost of impact
Risk Response Planning
Developing procedures and techniques to reduce the threat of risks and
enhance opportunities
Risk Monitoring and Control
Ongoing management of risks during project execution
Analyse Respond Control ReactIdentify
Scope of Risk Management

Risk Process PMBOK 2003
11.1 Risk Management Planning
– deciding how to approach, plan, and execute the risk management activities for a
project.
11.2 Risk Identification
– determining which risks might affect the project and documenting their characteristics.
11.3 Qualitative Risk Analysis
– prioritizing risks for subsequent further analysis or action by assessing and combining
their probability of occurrence and impact.
11.4 Quantitative Risk Analysis
– numerically analyzing the effect on overall project objectives of identified risks.
11.5 Risk Response Planning
– developing options and actions to enhance opportunities, and to reduce threats to
project objectives.
11.6 Risk Monitoring and Control
– tracking identified risks, monitoring residual risks, identifying new risks, executing risk
response plans, and evaluating their effectiveness throughout the project life cycle.

Project Risk Management Process Flow Diagram

Agenda
1
2
3
4
6
7
8
9

Risk Management Planning
 Plan the next phases/categories
 PMI lists the following inputs to Project Risk Management Planning
to create the risk management plan:
– Project Charter  Teilprojektbeschreibungsdokumente
– Organization’s risk management policies
– Defined roles and responsibilities
– Stakeholder risk tolerances
– Template for the organization’s risk management plan  FitPM
– Work breakdown structure  Projektpläne
 The main tool used is “planning meetings”.

Agenda
1
2
3
4
6
7
8
9

Risk Identification
 Inputs to risk identification:
– risk management plan
– items from project planning
– risk categories/types
– historical information
 The products of risk identification are risks, triggers, and inputs to
other processes (further action, etc.).
 Should not only be performed at the beginning of the project, but
also throughout the project’s life.

The key tools and techniques to use to identify risks are:
 Run a risk identification workshop (cross section of the project's
stakeholders)
 Peer reviews
 Review the risk assessment checklists created by the organization
 Interview key members of the project team
 Assumption analysis
 Examine sources of risk
 Study Lessons Learned from previous projects
Risk Identification Tools and Techniques

Using Inputs to Identify Risk Events/Sources of Risk
 Work breakdown structure / Projektpläne
 Contractual requirements or statements of work (SOWs), E-Vorlage
 Supplier contracts or customer agreements
 Field and marketing information
 Project plan assumptions
 Earned value (EV) data
 Lessons learned files from previous projects
 Company objectives and plans
 Other project-related plans
 Project schedule
 Review reports
 Project plan dependencies
 Resource sourcing !!!
 Sponsor or other stakeholder feedback
 As you progress on the project, some other areas to look at are:
 Change requests, Issue documents, Event log, Project status reports

Identify the Risk StatementIdentify the Risk Statement
 Beispiel: Performanz nach Konsolidierung Karat
-> Prob M, impact VH vs. M / M; Warum?
 Risks are described as having three parts:
– If <condition> and <dependency exists> then <impact will occur>
– If <condition>
• The event under which the risk will materialize
– e.g., IF GeeWiz Inc. does not deliver the Oracle interface by
November 2001.
– And <dependency>
• The reason for the project’s dependence on the risk
– e.g., AND it becomes necessary to develop an interface from
scratch.
– Then <impact>
• The quantifiable impact of the realized risk
– e.g., THEN our schedule will slip by 3 months and our costs will
exceed our budget by 10%.

Further Examples of Risk Statements
 IF the roof leaks because of the constant snowfalls, AND the project
team will be evacuated from the trailer, THEN we will not be able to
deploy data on schedule.
 IF I violate traffic rules, AND get one more ticket, THEN my insurance
company will drop me.
 IF loan is not approved by May, AND we cannot move into new house,
THEN we will have to extend our rent.

Agenda
1
2
3
4
6
7
8
9

Qualitative Risk Analysis
 Inputs:
– the risk management plan
– identified risks
– project status (early in life, later in life), project type (common,
uncommon), data precision, scales of probability and impact, and
assumptions.
 Tools used:
– applying risk probability and impact to individual risks
– a risk rating matrix that combines probability and impact of risks (such
as “low”, “moderate”, “high”)
 Qualitative risk analysis produces an overall risk ranking for the
project, list of risks for additional analysis and management, and
trends in qualitative risk analysis results.

When analysing the risk, consider the:
Probability of occurrence
Magnitude of loss or impact of each identified risk event
Severity of risk (Severity = Probability x Impact)
Evaluation factors include:
Precedence (Has the risk occurred before?)
Familiarity of operation (Has the work been undertaken before?)
Resources and skills
Time, cost, and quality
Probability (What is the likelihood of the risk occurring?)
Impact (What is the effect on the project or business?)
Win, Profit, Customer Satisfaction  Overall
Evaluation of Risk

Example: Define consequences/impact
Analyse
Consequence
Probability
Consequence Area Definition
Cost Entail budget overrun on more than 1 mill EURO in
<name on project>
High Time Entail that <name on project> is delayed more than 1
week
Quality Entail that subsequent projects can not be started
Cost Entail budget overrun on less than 1 mill EURO but
more than 0,1 mill EURO in <name on project>
Medium Time Entail that <name on project> is delayed less than 1
week but more than 1 day
Quality Entails that subsequent projects has considerable
negative influences
Cost Entail budget overrun less than 0,1 mill EURO in
<name on project>
Low Time Entail that <name on project> is delayed less than 1
day
Quality Entails that subsequent projects only has minor
negative influences

Risk Exposure Matrix
Exposure
Rating
Very High High Medium Low
Very High
High
Medium
Low
VH
VHVH
LH
HH
HH
HH
MM
M
M
M
Overall Impact
Probability
 overall impact: highest of each of the impact categories, e.g. L L M -> M

Agenda
1
2
3
4
6
7
8
9

Quantitative Risk Analysis
 Create a prioritized list of quantified risks, probabilistic analysis of the
project’s duration and costs, probability of achieving cost and time
targets, and trends.
 This is performed by the use of
– the risk management plan,
– identified risks,
– list of prioritized risks,
– list of risks for further analysis and management,
– historical information,
– expert judgment,
– and other inputs along with the tools of interviewing, sensitivity
analysis, decision tree analysis, and simulation.

Comparative Risk Ranking Tool
 Es werden den Risiken Buchstaben zugeordnet (möglichst nicht mehr als 5 bis 10 Risiken).
 Danach werden diese Risiken in unten stehende Tabelle eingetragen.
 Dann werden die Risiken in den einzelnen Stufen miteinander verglichen und der entsprechende
Buchstabe in die freien Felder eingetragen.
 Das Programm rechnet dann automatisch das am meisten genannte Risiko und man erhält das
entsprechende Risk-Ranking.
 Achtung: Es darf nicht sein, dass ein zwei oder mehrere Risiken das gleiche Ranking besitzen, da
jedes Risiko mit jedem anderen verglichen wird!
3 A A
1 B a B'
4 C a a C'
2 D b D'
0 E c c N
0 F c F'
0 G c G'
0 H d H'
0 I d I'
0 J J'
Ranking A B C D E F G H I J
2 4 1 3 5 5 5 5 5 5

AnalyzeAnalyze Time Frame and FrequencyTime Frame and Frequency
 Time FrameTime Frame
the period and/or points in time when risk consequences might
impact the project.
*Timing is relative to the expected length of the project.
 FrequencyFrequency
Characteristics of a risk which are likely to occur multiple times
throughout the project.
(e.g. das Thema Ressourcen jedes Quartal)
Near-term: Less than 30 days
Mid-term: Between 30 – 90 days
Far-term: Greater than 90 days

Assign Risk Ownership
In determining risk assignment consider:
 Accountability – who is ultimately held “accountable” for
determining the risk approach, as well as the success or failure
of mitigation and/or use of contingency plans.
 Responsibility – who is charged with developing and
implementing (or overseeing) risk mitigation actions and/or use
of contingency plans.
 Authority – who has the right and ability to assign resources for
mitigation and/or contingency

Risk Log 1/2
Ris
k ID
TP Kategorie Beschreibung Zeitl.
Ausprä
gung
Eintritt
s-
w´keit
(pre)
Impa
kt
(pre)
Score/
Exposu
re
(pre)
Score zur
Berechnung
nomalized risk
score
Strategie
1 Alg PMgmt Wenn die erforderlichen Ressourcen nicht bereitgestellt werden, führt dies zu Verzögerungen im Projekt. VH H VH 14 Eingrenzen
10 App/
DB
extern Wenn Probleme mit Fremd-SW entstehen, besteht eine hohe Abhängigkeit zu den Softwarelieferanten und deren
Support.
H M H 9 Accept
11 INET technisch Wenn keine Anpasssung der Domino- und Websphere basierten Applikationen auf Websphere Release 5.X
erfolgt, ist keine Konsolidierung vertretbar möglich.
M M M 5 Eingrenzen
12 INET technisch Wenn keine Migration der Applikationen auf WebSphere 5.X erfolgt, kann die Anzahl der Applikationen und
Server im Bereich Domino/WebSphere Applikationsserver nicht verringert werden.
M M M 5 Eingrenzen
14 Alg organisatorisch Wenn die Akzeptanz bei laufenden Projekten und in den Referaten gegenüber SOKO nicht besteht, sind Termine
und Zielsetzungen gefährdet.
VH H VH 14 Eingrenzen
15 App technisch Wenn die Zielsystemauslastung suboptimal geführt wird, sind die Zielzahlen gefährdert. L M M 5 accept
16 App technisch Wenn Cohosting durchgeführt wird, kann dies zu Destabilisierung, ohne vorheriges Monitoring sogar zum
Serverausfall führen.
L M M 5 accept
19 Alg organisatorisch Wenn SOKO relevante MA das Zeit Plus Programm annehmen, kommt es zu starken Terminproblemen. VH H VH 14 accept
23 App organisatorisch Abstimmung TP APP mit Serverbetrieb kann die In-Produktionnahme von Apps verhindern / verzögern
(Workshop war am 14.6. , bis jetzt sind immer noch nicht Betriebs-MA benannt
H M H 9 accept
24 App technisch Wenn erhöhte Anforderungen an Zielsystem-Messungen und oder andere Verfahren vor einer in-
Produktionnahme (eigentlich alle Anforderungen ungleich den im BC angenommenen) entstehen, erhöhen sich
die Aufwände und es kann zu Terminverschiebungen kommen.
H H H 9 eingrenzen

Risk Log 2/2
Strategie Maßnahmen Eintritts-
w´keit
(post)
Impakt
(post)
Score/
Exposu
re
(post)
Score zur
Berechnung
nomalized risk
score
Originator Datum
Aufnahme
Owner Status Links to
Issue/OP ID
Eingrenzen o quartalsweise Abstimmung der Ressourcen mit den RLs; o
bei punktuellen Engpässen Einsatz externer Ressourcen
o persönliche Ansprache der RLs durch die Projektleitung
o Kommunikation der möglichen Projektmitarbeiter die Zeitplus
planen, um Zeit für alternative Lösungen zu bekommen.
H M H 9 alle PM ongoing
Accept Risiko ist im BC berücksichtigt. Als Maßnahme bleibt die
Überwachung der Abbauzahlen
H L M 5 PM/Architektongoing
Eingrenzen Gespräch PL in HH 28./29.10. in HH M M M 5 Horneff Architekt ongoing
Eingrenzen Gespräch PL in HH 28./29.10. in HH M M M 5 Horneff Architekt ongoing
Eingrenzen o persönliche Kontakte zu Linienverantwortlichen und
Projektleitern pflegen
o Sichtbarkeit des Topsponsors/Managements für das Projekt
nach außen
o Initiierung von Personalgesprächen
H M H 9 Kern PM ongoing
accept Im BC berücksichtigt L M M 5 G.S. Architekt offen
accept Accept, da nicht für alle Services Abnahmeumgebungen
vorhanden sind
L M M 5 G.S. Architekt offen
accept siehe Risiko 1 VH L H 9 PM (O.K.) PM ongoing
accept H M H 9 eingetreten siehe OP 24
eingrenzen regelmäßige Abstimmungen zwischen SOKO-Architektur und
Betrieb
rollierender 3Monatsplan der TPL mit Betrieb regelmäßig
abstimmen
Performancemessung stärken
M M M 5 ongoing

Summary Risk Analysis
 Analyse: transform risk data into decision making information
 Define probability
 Define impact (e.g.for Win, Profit, Satisfaction)
 Overall impact: highest of each of the impact categories,
e.g. L L M -> M
 Risk Exposure: “product” probability and overall impact (s. matrix)
 Scale for impacts and probability: low, medium, high, very high
 Prioritisation/Ranking (s. e.g. comparative risk ranking)

Normalized Project Risk Scoring:
 Rate exposure of each risk:
2 (low), 5(medium), 9(high), 14 (very high)
 Sum all scores (getrennt nach Impact Kategorien und overall)
 normalized score = sum of risk scores * 10 / number of risks
(risks no longer considered must still be listed as “low”, otherwise the
overall risk will be too high)
 OVERALL RISK EXPOSURE
– 21–40 = Low
– 41–60 = Medium
– 61–80 = High
– 81+ = Very High

Normalization: Use, Strengths, and Weaknesses
 Use:
– Qualitative elements must be weighted
 Strengths:
– Helps with comparison of different projects
– Allows for comparison of risk categories (e.g. Win, Profit, Customer
Satisfaction)
 Weaknesses:
– Tends to result in „High“ overall risk, especially if only few risks are
used
– All identified risks must be retained, including those no longer
considered
• Risks no longer be considered must be listed as „Low“, otherwise
the overall risk will be to high
– The result is easy to manipulate

Risk Analysis Tools
 Monte Carlo simulation and Sensitivity Analysis
aid the project management community in determining which variables of a
project most impact the project’s possible outcomes, and by how much.
 For example, using Monte Carlo simulation one can obtain statistical
probabilities of project variable’s impact on the overall project expected value
(such as, maximum and minimum impact of a variable on the project’s expected
value).
 From this information on project variables impact, a tornado diagram could be
created to analyze all variables to identify which ones should be kept as a priority
to focus on to manage the project’s outcome.

Risk Analysis Tools
Sensitivity Analysis - Tornado Diagram

Risk Analysis Tools
Decision Tree with EMV (Expected Monetary Value)

Risk Analysis Tools
Pareto Analysis
 80/20 Rule
 Examples*
– 20% of your customers provide 80% of your sales
– 20% of your products provide 80% of your sales
– 20% of your products provide 80% of your profit
– 20% of your products provide 80% of your problems
 Useful for*:
– Prioritizes and focuses resources where they are most needed.
– Measures the impact of an improvement by comparing before and
after.
– Visually displays the relative importance of causes, problems or
other conditions.

Agenda
1
2
3
4
6
7
8
9

 Avoid
 Accept
 Transfer
 Contain (kann neue Risiken erzeugen):
– Mitigation, specific actions to lower impact, probability or both
(wir tun was, die Kosten fallen jetzt an)
– Risk contingency planning, prepare a plan of action
(nur Plan vorbereiten für den Fall, falls das Risiko eintritt)
 Insure
 Risk Reserve
– Risk contingency reserve (within project budget)
– Risk management reserve (outside project budget)
Risk Response Planning Strategies

Factors to Consider When Planning Risk Response
 Many factors influence the selection of a risk mitigation strategy,
including:
• Project phase and application
• Size
• Priority
• Complexity
• Expense
• Time available
• Required level of detail
• Ease of use
• Resource availability
• Contract type
• Terms and conditions
• The project manager's authority, accountability, and ability
• Commitment from the project manager and upper management
• Customer satisfaction

Risk Response Sheet
Response
strategy
Response actions Cost Effec. New risk as a result of the strategy
Accept none VG
Avoid
Transfer
Insure
Contain
Mitigate
Contain:
risk cont.
plan
Risk
reserve
Select best strategies: cost/effectiveness/new risk technique
(VG: very good, G: good, NG: not good)
reassess project risk – post response -> new impacts, probabilities, exposures,
normalized score

Impact of Different Risk Options

Remove high risk element(s) from proposal
Add assumptions to define boundaries of task / function / risk
Add appropriately skilled resources
Transfer responsibility to the customer - but be careful that customer
has the capability and commitment to perform (z.B. GBA !!)
Recommend phased development approach
Integrate special checkpoints by management
Include Level of Effort (LOE) tasks
Examine alternatives
Develop containment & contingency plans
Risk: Containment Actions

Ensure assumptions are accurate
Establish firm baseline
Detailed change control / management
Assume risk but add premium
Document analysis, tradeoffs, decisions
Contact other QA representatives for ideas
NOTE: Having a contingency plan does
not necessarily reduce the risk rating
Risk: Containment Actions (continued)

Risk Triggers
 An important part of defining the risk containment plans is risk triggers.
 Risk triggers are indicators that specify when an action needs to be
taken. The format for defining risk triggers is as follows: If the trigger
event happens, then initiate the action plan.
 Examples of triggers and action plans include:
• If the power is out for more than 30 minutes, start using the
generator.
• If the product delivery from the OEM vendor is n days late, then
contact the other vendors to move their shipments back.
 Effective triggers:
• Provide an early warning, which gives the team enough time to
take appropriate action or focus extra attention on the risk
• Do not initiate actions unnecessarily
• Are easy to calculate and report

Agenda
1
2
3
4
6
7
8
9

Risk Monitoring and Control
 Workaround plans, corrective action, project change requests, updates
to the risk response plan, a risk database (repository for information),
and updates to the risk identification checklists are all products of risk
monitoring and control.
 Products from previously-discussed processes are used to create
these products (risk management plan, risk response plan) as well as
project communication, additional risk identification and analysis (as
part of the overall “Controlling” process), and scope changes.
 Tools and techniques used are project risk response audits, periodic
risk reviews, earned value analysis, technical performance
measurement and additional risk response planning.
 Watching and periodically reevaluating the risk for changes

Questions to Consider
 Is the risk still possible / Is the event still risk?
 Is the probability still the same?
 Is the impact still the same?
 Is the teams´s tolerance still the same?
 Are there new risks?

Risk Tracking and Control
 Critical success factors:
– execute the process
– reflect response strategies/actions in the
WBS
– develop alternatives
– communicate, get buy-in on selected
alternatives
– execute the action plan
 Triggers:
– regular assessment
– key events
– Suppliers
– key changes
– human resources
– Technical
– Customer
– Competition
– other environmental changes
 Risk Reaction
– analyse the impact of the risk occurrence
– update risk history
– …

Risk Closure
 Document the rationale for closure
 Focus on information that can be used later, either within the
current project or by future projects. Example of the type of
information to be captured include:
– Successful containment plans and why they were successful
– Failed containment plans and the reason for that failure
– Risk relationships and dependencies that were not obvious
– Relevant data from various analyses, especially costs and benefits of
mitigation plans
 Close the risk and update the status.

Agenda
1
2
3
4
6
7
8
9

Summary
 Risk Management is iterative and continuous process for the life of a
project.
 It is concerned with identifying, analyzing and responding to project risks.
 The benefit of risk management process is safeguards that you have
done your best to minimize the probability and consequences of adverse
events.
 It’s a standard part of project management because it helps to make
educated decisions that are vital to the project success.

Recommendations
 Risk identification needs more focus during the controlling process
(during the project’s execution).
 Positive risks need to be identified and managed to optimize project
success. (z.B. Image over IP)
 Tools such as sensitivity analysis (tornado diagrams), utility functions,
influence diagrams, decision trees, and SMART analysis could aid risk
identification and quantification.
 Involvement of program-level management in individual project risk
management oversight would ensure the same level of risk management
across program projects. Enforcement of the expected risk behavior and
minimum standards for risk management could be increased at the
project-level.
 Increased priority and time available for risk management tasks at the
project-level could be implemented by program management.

Identify and understand risk event
Plan to handle risk events
Incorporate Risk Management into the Project Management Planning
Process
Use the right strategies (for example, containment or contingency) to fit
the situation
Monitor risk events on a regular basis
Reassess events after each risk event
Don't try to do it
SOLO
The Project Managers Role in Risk Management

Backup

Risk Identification Workshop
– Identification
– Prioritisation
– Quantification
– Response Development
– Mitigation Strategy
– Control

Utility Theory
 Suppose that, after some questioning, the builder is able to make the
following statements:
 'I am indifferent between receiving $120,000 for certain or entering a
lottery that will give me a 0.9 probability of $150000 and a 0.1
probability of winning $0.‚
lottery that will give me a 0.85 probability of winning $150 000 and a
0.15 probability of winning $0.‚
lottery that will give me a 0.75 probability of winning $150 000 and a
0.25 probability of winning $0.'

Risk Analysis Tools
Utility Theory – Risk Adverse/Neutral/Seeking
 risk adverse for dollar values below $100,000, but is a risk seeker at higher dollar values (above
$100,000). This is because the utility plot shows convex curvature at higher dollar values, and
concave curvature at lower dollar values.

Risk Analysis Tools
Decision Tree with Expected Utility
 Konträres Ergebnis zum Decision Tree mit EVM

Risk mgmt

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Risk mgmt

Similar to Risk mgmt (20)

Recently uploaded

Recently uploaded (16)

Risk mgmt

Editor's Notes