Comments from Wiki Author: I started this project as a detailed summary of each section. Like
paraphrasing to show that I covered that section. But this approach is evolving into more of
comments on the sections, and maybe problems that can occur in real world implementation.
Chapter 5 starts to deviate from original approach. Desired effect is that a better grade will
result from a discussion than a summary. Promotional for RMP: “Use Risk Management Process
or Use a 12-step program for Management.” This wiki is meant to be a link between high brow
tech speak to a more Risk Management for Dummies style.
Part II – Risk Management Process
This Part contains:
Chapter 4 – Identify Risk
Chapter 5 – Analyze Risk
Chapter 6 – Plan Risk
Chapter 7 – Track Risk
Chapter 8 – Resolve Risk
These chapters will cover predictable risk management results.
Identify Risk
4 - Identify Risk
Discussion covers the Risk Identification Process.
Analyze
Risk
Plan Risk
Track R
4.1 – Define the Risk Identification Process
External View contains process controls, process inputs, process outputs, and process
mechanism.
Internal View contains process activities.
4.1.1 Process Goals
The Risk Management Process has been successful when these topics are accomplished






Encourage input of perceived risk from the team.
Identify risk while there is time to take action
Uncover risk and sources of risk.
Capture risk in a readable format
Communicate risk to those who can resolve it.
Prevent project surprises.
4.1.2 Process Definition
Process Controls
Project Resources
Project Requirements
Risk Management Plan
Process Inputs
Uncertainty
Knowledge
Concerns
Issues
Identify Risk
Process Mechanisms
Risk Checklists
Risk Assessment
Risk Management Form
Risk Database
Process Output
Risk Statement
Risk Context
4.1.3 Process Activities
Conduct a Risk Assessment
Uses established criteria to identify and evaluate risk. These criteria include
likelihood of occurrence, consequence, and time frame for action.
Identify Risk Systematically







Checklist
Interview
Meeting
Review
Routine input
Survey
Working group
Define the Risk Attributes
Probability
Almost certainly
Highly likely
Very good chance
Probable
Likely
Probably
We believe
Better than even
We doubt
Improbable
Unlikely
Probably not
Little chance
Almost no chance
Highly unlikely
Chances are slight
100%
0%
Document Identified Risk
Risk statement should contain issue, probability, and consequence. Use a form
to create a familiar frame of reference.
Communicate Identified Risk
To communicate risk affectively uses verbal and written forms. Both forms have
their purpose.
Verbal form is used to open a dialogue between team members. Written form is
used as a historical document.
4.2 Develop Risk Checklists
Risk Checklists are important because they represent a systematic way to identify risk.
Include the project’s critical success factors, items in the critical path of schedule, and
itemize the project interfaces, internal and external.
SEI software risk taxonomy can save a lot of time.
4.2.1 Software Risk Taxonomy
Product Engineering
1. Requirements
Stability
Completeness
Development Environment
1. Development Process
Formality
Suitability
Program Constraints
1. Resources
Schedule
Staff
Clarity
Validity
Feasibility
Precedent
Scale
Process control
Familiarity
Product control
Budget
Facilities
2. Design
Functionality
Difficulty
Interfaces
Performance
3. Development System
Capacity
Suitability
Usability
Familiarity
Reliability
System support
2. Contract
Type of contract
Restrictions
Dependencies
3. Project Interfaces
Customer
Associate Contractors
Testability
Hardware constraints
Nondevelopmental software
3.Code and Unit Test
Feasibility
Unit test
Coding/implementation
4.Integration and Test
Environment
Product
System
5. Engineering
Specialties
Maintainability
Reliability
Safety
Security
Human factors
Specifications
Deliverability
4. Management Process
Planning
Project organization
Management experience
Project interfaces
Subcontractors
Prime contractor
Corporate management
Vendors
politics
4.Management Methods
Monitoring
Personnel management
Quality assurance
Configuration management
5.Work Environment
Quality attitude
Cooperation
Communication
Morale
4.2.2 Work Breakdown Structure
WBS is the framework for identifying specific project risk.
Time spent on unplanned work reduces time spent on planned work.
This could cause problems including schedule slips and cost overruns.
4.3 Define the Risk Assessment Method
Objectives include training techniques to identify risks. The method is based on concepts
developed by the SEI Risk Program.
4.3.1 Assessment Preparation
In preparation, an assessment team reviews the project profile. This Project Profile
contains Company organization, Project data, System description, and Project history.
The preparation can be broken down into the following tasks
1.
2.
3.
4.
5.
6.
Select and train the assessment team.
Review the project profile.
Select the interview participants.
Prepare the risk assessment schedule.
Coordinate the meeting logistics.
Brief the project participants.
4.3.2 Interview Session
SEI Taxonomy-based questionnaire(TBQ) is used by the assessment team tod conduct
interviews of peer groups
TBQ is a risk identification mechanism of high importance.
The interview protocol will al be used in the interview session. The protocol will identify and
evaluate risk.
Interview protocol is used to set up the environment, so that all views can be voiced.
The interview session will include the followings roles: Interviewer, recorder, and observer.
The interview session will include the following tasks: Interview the peer group
Record the risks
Clarify the risk statements
Observe and document the process results
4.3.3 Preliminary Risk Analysis
Preliminary risk analysis comprises the following tasks:
Evaluate the identified risks.
Evaluate the interview session.
Categorize the risks.
Enter the risks in the risk database.
4.3.4 Results and Retrospective
Interview Session Results are summarized and the team is briefed.
Feedback is recorded and the risk database is updated.
4.4 Develop the Risk Management Form
Risk Management form is used as a risk identification mechanism that can be used by any
member of the team.
4.5 Establish the Risk Database Schema
Database Schema is the Risk database design that ties the requirements and risk and
risk attributes together.
5 Analyze Risk
Chapter 5 covers risk analysis process. Also will cover tools and techniques for
evaluation and estimation of Software risk.
5.1 Define the Risk Analysis Process
Author uses the same wording in each X.1 paragraph. This is good for a reference
manual, but bad for capturing reader interest.
He goes over how the risk analysis process can be broken down into internal and
external views.
External- process controls, inputs, outputs, and mechanisms.
Internal- transforms used on inputs to make outputs.
5.1.1
Process Goals
He lists the quality goals for the risk analysis process.
Later some of these same goals are explained in detail under process activities.
Goals



Analyze risk in a cost efficient manner.
Refine the risk context.
Determine the source of risk.



5.1.2
Determine the risk exposure.
Determine the time frame for action
Determine the highest-severity risks.
Process Definition
Here he explains what a IDEF0 diagram is just like in the last chapter. If a reader
is using this as a real resource they would have already come across the
definition when first mentioned. It seems like the author had to fill a little space.
Process Controls
Project Resources
Project Requirements
Risk Management Plan
Process Inputs
Risk Statement
Risk Context
Analyze Risk
Process Output
Risk List
Process Mechanisms
Evaluation Criteria
Analysis Techniques
Analysis Tools
Risk Database
Process controls - This section is the same as in chapter 4. Author acknowledges
this with a note to see ch. 4.
Process inputs - the process inputs for “Analyze Risk” is the same as the process
output of identify risk. We need a risk statement and Risk Context to start this
step.
Risk Statement – is a concise declaration of risk in terms of
Issue probability and consequence.
Risk Context – puts the risk statement in context by
providing events, conditions, constraints,
assumptions, circumstances, contributing
factors, and related issues.
Note: Risk Context will be refined in the “Analyze Risk”
step.
Process outputs - The process outputs are conflicting between the diagram and
the process output paragraph. The paragraph doesn’t just mention Risk List, but
also includes a refined Risk Context.
Risk List – Inventory of risks that shows the relative
ranking of all identified risks.
Refined Risk Context (unofficially) – like metadata for the
risk statement, but refined to include a risk category.
Process Mechanisms – Provides structure for the process activities. Basically
detailed descriptions of these mechanisms are contained in the next section.
Evaluation Criteria
Analysis Techniques
Analysis Tools
Risk Database
5.1.3
Process Activities
Remember it’s all about the Risk List! So these process activities are all mean to
transform risk statements into a Prioritized Risk List.
To accomplish such a transformation the following Activities are necessary:







Group similar and related risks.
Determine risk drivers.
Determine source of risk.
Use risk analysis techniques and tools.
Estimate the risk exposure.
Evaluate risk against criteria.
Rank risks relative to other risks.
Let’s explain each one of these with a bit of detail.
Group Similar and Related Risks – Use risk category to accomplish Grouping of
similar and related risks. Handle duplicates by flagging them as such. Be sure to
link related risks or risks that have effects on one another.
Determine Risk Drivers – Here we have an activity that will modify/refine the
Risk Context. Risk Drivers cause the probability and consequence of Software risk
to fluctuate.
Risk Driver Types:
Performance – related to tech specs
Support – completely left out by author
Cost – factors related to cost-estimation models
Schedule – items on critical path of schedule
Determine Source of Risk – ask why 5 times.
Note: The five times rule seems to simple to be useful. All risk sources
aren’t uniformly 5 levels deep.
What about asking why until risk source is beyond management
control.
Use Risk Analysis Techniques and Tools – handle conflicting cost and
performance goals, uncertainty, and risk preference.

Structure – states attributes of outcomes and relationships
between outcomes



Analyze – analyze the decision model. Details in 5.2.
Evaluate – quantify decision model probabilities. Details in 5.3.
Communicate – share results to stakeholders.
Estimate the Risk Exposure – RE = P * C where P is probability of risk and C is
consequence of risk occurrence.
Evaluate Risk against Criteria - ensures that all risks will be judged against the
same standard.
Time
Frame
Short
Medium
Long
Low
5
7
9
Risk Exposure
Moderate
2
4
8
High
1
3
6
Risk Severity
Rank Risks Relative to Other Risks – sort risks by evaluation criteria, so high
priority risks are reviewed first. This step supports the Top-N Risk List report.
5.2 Define Risk Analysis Techniques
This section will focus on refining risk statement and risk context using risk analysis
techniques.
5.2.1
Causal Analysis
There are two techniques for Causal Analysis, fishbone diagram and five whys.
Somehow Causal Analysis is also a three step process:



Determine the cause of the error.
Determine the actions that will prevent the error in the future.
Implement these corrective actions
Sounds like a step for a programmer instead of risk analysis team. In my limited
experience, EPGs rarely get down into the “weeds” like the example in this
section.
5.2.2
Decision Analysis
Decision Analysis Structures decisions, represents real-world problems using
models. These models can then be analyzed to gain insight.
This section provides two graphical models for Decision Analysis, influence
diagrams and Decision Trees. DTs look more simple, and logical, but as the
number of nodes increase, the branches will grow by 2^x.
5.2.3
Gap Analysis
Gap Analysis is used to determine the difference between two variables. This is
basically a qualitative chart about how surveyors feel about different categories
of Risk Management. Because of the abstract nature of importance, any
information other than perceived lack or abundance in a category seems farfetched. This section also explains the use of Radar charts for Gap Analysis.
5.2.4
Pareto Analysis
Pareto Analysis sorts the issues in the order they should be addressed. The core
of this analysis technique is the 80/20 rule. It states, 20% of the sources cause 80
% of the problems. The output of Pareto Analysis is the Pareto Chart. A Pareto
Chart come in two flavors, either Identified Risk or Risk Exposure.
5.2.5
Sensitivity Analysis
Sensitivity Analysis is used to determine the sensitivity of a model, by setting
inputs of the model to the extremes. This analysis technique uses Tornado
Diagrams to identify the most sensitive variables. Utility functions have been
covered in part one, and in this section a new version is referenced. Exponential
Utility function has an addition parameter known as the risk tolerance. This
parameter is used to vary risk aversion. Sensitivity analysis of a Exponential
Utility function displays the point of Risk tolerance where the decision of what
branch to take changes.
5.3 Define Risk Evaluation Criteria
Evaluation Criteria define probability, consequence and time frame for action.
5.3.1
Probability
Probability
>80%
61-80%
60-41%
Uncertainty Statement
Almost certainly, highly likely
Probable, likely, probably, we believe
We doubt, improbable, better than
even
Unlikely, probably not
Highly unlikely, chances are slight
40-21%
1-20%
5.3.2
5.3.3
Evaluation
5
4
3
2
1
Consequence
Criterion
Cost
Low
Moderate
<1%
<5%
Schedule
Slip(week)
1
2
High
Critical
<10%
>10%
4
>4
Technical
Slight effect on performance
Moderate effect on
performance
Severe effect on performance
Mission cannot be
accomplished
Time Frame
Time Frame
1 month
2 months
3 months
Evaluation
Short
Medium
Long
5.4 Establish the Risk Prioritization Scheme
Risk Prioritization is required to provide focus risk importance. The difference
between the follow schemes are rank verses rate.
5.4.1
Nominal Group Technique
Turns individual priorities into team priorities, by having the individuals rank the
risks by importance to them. Then each risk is evaluated and scored on the
individual inputs.
5.4.2
Weighted Multivoting
Weighted Multivoting rates risks based on a consensus prioritization scheme.
Basically, each team member is given a equal number of points, and they
distribute them among the risks. The number of points a risk receives is
proportional to the importance.
6. Plan Risk
The chapter subject matter includes



What are the activities of the risk planning process?
When should you use each of the strategies for risk resolution?
How do risk scenarios help to monitor risk?
6.1 Define the Risk Planning Process
Internal verses external
6.1.1
Process Goals
Goals we are trying to satisfy during the Risk Planning Process





Provide visibility for key events and conditions.
Reuse successful risk resolution strategies.
Optimize selection criteria (e.g., risk leverage or risk diversification).
Understand the next action for each high-severity risk.
Establish automatic triggering mechanisms.
I’m sure will see these again under process activities.
6.1.2
Process Definition
Process Controls
Project Resources
Project Requirements
Risk Management Plan
Process Inputs
Risk List
Measures
Plan Risk
Process Output
Scenarios
6.1.3
Process Activities
Risk Planning Process Activities include:





Develop Risk Scenarios for high-Severity risks.
Develop Risk resolution alternatives.
Select the risk resolution approach.
Develop a risk action plan.
Establish thresholds for early warning.
Develop Risk Scenarios for High-Severity Risks – Here we use the Top-N Risk List
developed in the Analyze Risk Process, and we develop scenarios for the high
priority risks on the List. Follow these three steps to develop scenarios.



Think about the risk as if it had occurred.
State the risk scenario as if the risk had already happened.
List the events and conditions that would precede the risk occurrence.
Develop Risk Resolution Alternatives – Risk Resolution alternatives are options
that when implemented resolve risk. A Risk Resolution strategy uses the
following resources to resolve risk:







Acceptance
Avoidance
Protection
Reduction
Research
Reserves
Transfer
Make sure that each strategy developed contains objectives, constraints, and
alternatives. More on this in 6.2
Select the Risk Resolution Approach – This step narrows the set of options down
to the best alternatives.
Develop a Risk Action Plan – The Risk Action Plan contains details on the risk
resolutions. A Risk Action Plan documents the approach, resources required, and
approval authority. It also contains the following:








Approval Authority
Responsible person
Resources required
Start date
Activities
Due date
Actions taken
Results achieved
Establish Thresholds for Early Warning – risk action plan can be for future
events. This causes the potential for a risk plan not to be addressed in time
because it was overlooked. A triggering mechanism can be used to prevent this.
These triggering devices should be based on quantitative targets and thresholds.
Another word for targets, in this case is goals. By using a minimum performance
value, a warning level or threshold can be defined. Once the actual performance
dips below the minimum performance value then action may be required to
resolve risk.
6.2 Define Risk Resolution Strategies
This section will cover strategies for risk resolution.
6.2.1
Risk Acceptance
Risk Acceptance is a strategy used when the risk consequence is accepted, and
no resolution occurs.
This section uses the loss of an employee as an example. The risk consequence is
that cost of a new hire.
6.2.2
Risk Avoidance
Risk Avoidance is a strategy where the risk is eliminated altogether. This strategy
is favored in lose-lose situations.
This section contains an above average example that illustrates a lose-lose
situation that risk avoidance may be an acceptable strategy.
A good quote from this chapter is “Use a risk scenario to determine if you have
the organizational support, staff experience, and risk management expertise to
win on the project, not just the proposal.”
6.2.3
Risk Protection
Risk Protection is a strategy to introduce redundancy to avoid risk. Example
includes FAA control system design that included tandem computers.
6.2.4
Risk Reduction
Risk Reduction is a strategy that uses the following to minimize risk:



Mitigation
Prevention
Anticipation
Risk Reduction lowers the probability of risk occurrence and/or consequence.
6.2.5
Risk Research
Risk Research is a strategy that is used when more information is required.
Types of Risk Research tools include:



Prototyping
Consumer questionnaires
Trade studies
Basically, Risk Research occurs when empirical information is bought.
6.2.6
Risk Reserves
Risk Reserves is a strategy that uses contingency funds and built-in schedule
slack. This is a good strategy to use when there’s uncertainty in cost or time.
When using this strategy it’s a good idea to proportion the reserves with the
proportion of unknowns associated with individual subsystems.
6.2.7
Risk Transfer
Risk Transfer is a strategy that uses another person, group, or organization to
shift the risk to. The best time to use this strategy is when another entity is in
control. At first glance this sounds like a way to blame another entity for when
something unfavorable happens, but the example does a good job of clarifying
the nature of risk transfer.
6.3 Define Selection Criteria
Helps determine the best alternative to resolve risk.
6.3.1
Risk Leverage
Risk Leverage measures the relative cost-benefit of potential risk resolution
activities. Associated terms are Risk Resolution Cost and Risk Exposure.
Risk Resolution Cost is the cost of implementing a particular risk action plan. Risk
Leverage is used to determine the risk resolution activity with the highest
payback.
Risk Leverage = (RE(before) – RE(after))/Risk Resolution Cost
6.3.2
Risk Diversification
Risk Diversification reduces risk by distribution. Basically, don’t rely on single Risk
Resolution to handle all Risk. Try to reduce single points of failure.
6.4 Develop the Risk Action Plan Template
Purpose: Capture the risk resolution strategy in a standard format.
When developing the Risk Action Plan include events and condition of the risk
scenario.
A complete Risk Action Plan will include:












Risk resolution strategy
Objectives
Alternatives
Approach
Approval Authority
Responsible Person
Resources Required
Start Date
Activities
Due Date
Action Taken
Results Achieved
7. Track Risk
Risk monitoring is not a passive activity!
Indicator is an aspect of a project that implies a value of another aspect of the project
without directly specifying the quanity.
Leading indicator means aspect has a predictive capability.
This chapter will focus on the risk tracking process. It’s all about monitoring the risk status.
Answered questions of this chapter include
Process
Controls
Process Inputs
Process
Mechanisms
Process Output
Plan
Risk
Targets
Scenarios
Project
Listare the activites ofQuantitative
 Risk
What
the
riskResources
tracking
process?
Resolution
Strategies
Thresholds
Project
Requirements
 Measures
How can static measures indicate dynamic risks?
Criteria
Risk Action Plan
RiskSelection
Management
Plan
 Metrics
What types of triggers provide
notification
of
unacceptable
risk?
Risk Database
Triggers
7.1 Define the Risk Tracking Process
internal verses external again.
7.1.1
Process Goals
Process is completed successfully when the following goals are met:






7.1.2
Monitor the events and conditions of risk scenarios.
Track risk indicators for early warning.
Provide notification for triggering mechanisms
Capture results of risk resolution efforts.
Report risk measures and metrics regularly.
Provide visibility into risk status.
Process Definition
Process Controls
Project Resources
Project Requirements
Risk Management Plan
Process Inputs
Scenarios
Thresholds
Risk Status
Track Risk
Process Output
Measures
Metrics
Triggers
Process Mechanisms
Tracking Techniques
Tracking Tools
Risk Database
7.1.3
Process Activities
The following activities are required to monitor risk status and notify
team/management when a risk resolution needs to be triggered.




Monitor risk scenarios
Compare threshold to status
Provide notification for triggers
Report risk measures and metrics
Monitor Risk Scenarios – These scenarios are important because they can
provide evidence that a risk is starting to occur.
Compare thresholds to Status – Watch for indicator values outside accepted
ranges. If this occurs then a trigger device has been tripped.
Provide Notification for triggers- make sure the right people are notified once a
trigger is tripped.
These are the types of triggers (should be in a different section)




Periodic event
Elapsed time
Relative variance
Threshold value
Report Risk Measures and Metrics – a lot of metrics exist.
Here are a few measures:



Logged Risk
Risk Exposure
Risk Management Index
7.2 Define Risk Tracking Techniques
Using automation software for tracking can greatly help free up personnel.
Trend is a time series of metrics data.
Technical Performance Measure describe goals for performance.
Tracking performance measures are essential for monitoring risk.
These are the three important step to using static measures:



7.2.1
Define warning levels of unacceptable status as thresholds
Monitor status indicators in terms of measures and metrics.
Regulate the risk action plan execution using triggers
Project Control Panel
A Project Control Panel gives us a visualization of indicators that are important to
management and technical metrics.
Some companies may call these dashboards.
Some features of an automated control panel:






Monitor project health by a core set of metrics.
Group metrics into gauge clusters.
Convey dissimilar metrics using different formats.
Highlight safe operating areas and warning levels.
Update display based on real-time work flow.
Display lower-level and trend data.
Key Indicators of the project control panel include:






7.2.2
Progress
Size
Change
Quality
Risk
Staff
Software Measures
Software Measures indicate how close a project is to meeting its process and
product goals.
Key word for this section is Goal/question Metric(GQM) paradigm. Then 3
manuals are listed that implement this paradigm.
GQM manuals are:



Metrics Guidebook for Integrated Systems and Product Development
Practical Software Measurement
Software Measures and the Capability Maturity Model
7.3 Define Risk Measures and Metrics
Use these measures to determine risk management metrics:










Number of risks – risks being managed
Number of logged risks – number or risk in database
Risk category – number of risk in a particular category, when this statistic is
compared to one another the category with highest number could have
largest affect on project.
Risk exposure – is the product of Probability of unsatisfactory outcome to the
Consequence of that outcome.
Risk severity – a level of relative risk
Risk leverage – measures the cost-benefit of candidate risk resolutions
Risk threshold – value that triggers a particular risk action plan. Without this
the risk action plan may not occur in time.
Risk indicator – current value of measures watched for risk
Risk Management Index - summation of risk exposure for all risks relative to
the total cost of the project.
Return on investment- summation of savings for total risks over the cost of
the risk management team and resources used for risk management.
7.4 Define Triggering Devices
Triggers give us three basic functions.
These functions include:



To Activate
To Deactivate
To Suspend
Four Types of Triggers were mentioned earlier.
8. Resolve Risk
This chapter defines the Risk Resolution Process.
The questions answered in this chapter are:



What are the activities of the risk resolution process?
How can you creatively resolve risk?
When is the level of risk acceptable?
8.1 Define the Risk Resolution Process
Internal verses external
8.1.1
Process Goals
Risk resolution process is complete when the following goals are met:









8.1.2
Assign responsibility and authority to the lowest possible level.
Follow a documented risk action plan.
Report results of risk resolution efforts.
Provide for risk aware decision making.
Determine the cost-effectiveness of risk management.
Is prepared to adapt to changing circumstances.
Take corrective actions when necessary.
Improve communication within the team.
Systematically control software risk.
Process Definition
Process Controls
Project Resources
Project Requirements
Risk Management Plan
Process Output
Risk Status
Acceptable Risk
Reduced Rework
Corrective Action
Problem Prevention
8.1.3
Process Activities
Resolve Risk Activities include:




Respond to notification of triggering event
Execute the risk action plan
Report progress against the plan
Correct for deviation from the plan
Respond to Notification of Triggering Event – Triggers should give ample time
for response from management.
When such a trigger occurs, a review of reality and an updated determination of
the time frame for action should be completed.
Execute the Risk Action Plan – make sure the risk action plan to resolve risk is
thoroughly documented.
Miscommunication must be avoided.
The author suggests using phases of software development to implement details
of the execution of the Risk Action Plan.
When listing actions for risk resolution, keep in mind to …





Think about working smarter
Challenge yourself to find a better way
Exploit opportunities
Be prepared to adapt
Use common sense
Report Progress Against the Plan – Be sure to report the results of any risk
resolution efforts.
Make sure that the entire team regularly reviews the following to ensure tisk
aware decision making:



Risk Status
Measures
Metrics
Correct for Deviation from the Plan – Be agile when deviation from the plan
occurs. Quickly recover by taking corrective action.
8.2 Define Risk Resolution techniques
The following subsections will be used repetitively to resolve risk.
8.2.1
Creativity
Creativity is inventiveness in coming up with new ideas.
Creative Process is how we come up with new ideas
Innovation style is how we go about the creative process
Note: I don’t think one can be taught how to be creative. Our amount of
creativity is more than a technique. It’s a function of our experience and how
easily we apply those experiences to seemingly unrelated situations. Maybe that
in itself is a even more narrow-view of creativity.
Here are the four innovation styles:




8.2.2
Envisioning
Experimenting
Exploring
Modifying
Collaboration
Winner for the best quote so far is Michael Schrage with his quote from Shared
Minds, “[collaboration is] two or more individuals with complementary skills,
interacting to create a shared understanding that none had previously possessed
or could have come have come to on their own”
When involved in the collaboration try to overcome these problems:



Sending the wrong message
Receiving the wrong message
Communication link breakdown
8.3 Define Risk Management Return on Investment
This topic was discussed before, but let’s see what is new. Oh it’s specific to risk
action plans. It’s worth to show the Cost Avoidance Calculation table
Outcome
Risk did not occur because
of successful risk
resolution.
Cost Avoidance
Max(RE)
Rationale
Cost avoidance is based on
the maximum estimate of
risk exposure. Using the
Max function promotes
periodic updates of the
risk action plan to reflect
more accurate estimates
of probability and
Risk did not occur because
of good fortune.
0
Risk occurred; the
consequence is less than
the initial estimate.
Max(Ct) – Ct=1
Risk occurred; the
consequence is equal to
(or greater than) the initial
estimate.
0
consequence.
Cost avoidance is zero if
no risk management
efforts were initiated.
Cost avoidance is the
difference between how
bad it could have been and
how bad it was when the
consequence was realized.
Risk resolution strategies
were ineffective.
Investment in risk
management has a zero
return. No cost was
avoided. (Negative returns
are not used because they
promote use of worst-case
estimates.)
8.4 Develop a Corrective Action Procedure
To make a corrective action procedure you must follow these four steps:




Identify the problem
Assess the problem
Plan action
Monitor progress