Complying with the CMMI Requirements for Risk Management

1
Complying with the CMMI Requirements for Risk
Management

• Rick Hefner, TRW
• rick.hefner_at_trw.com310.812.7290
• Southern California SPIN28 September 2001

2
Agenda

• A Definition of Risk
• A Structured Risk Management Process
• CMMI Requirements for Risk Management
• Risk Management Resources

3
Fundamental Concepts

• Risk management
• A management discipline based on the continuous
  identification and control of events that can
  cause unwanted change
• Proper management requires a connection among
• Risk management
• Project planning tracking
• Measurement metrics
• Process improvement activities (project
  corporate)
• Sponsor/contractual acquisition constraints

4
What is a Risk?

• Youve carefully planned out a project
• The customer supplied you the users requirements
• Estimated 5 developers could develop the software
  in 6 months
• Placed subcontractor on contract to deliver the
  test environment
• What could go wrong?
• All 5 developers may not be available
• May get assigned developers than expected (and
  take longer than you expected)
• Developed may not be as productive as
  expected(and take longer than you expected)
• The subcontractor may deliver later
• The subcontractor may not deliver what you
  expected
• The requirements may not be complete or
  consistent
• The customer may not have supplied the real
  users requirements
• Etc.

5
Structured Risk Statements

• Risk (severity/importance) probability of
  adverse event X impact if the event occurs
• Risks should be stated in a structured manner
• If adverse event happens, then impact
• Examples
• If the vendor is two weeks late with the test
  environment,then delivery to the customer will
  be three weeks late
• If the customer does not identify a key user
  requirement,then the system will not perform as
  the users desire and customer satisfaction will
  be diminished by 50
• Impacts could be to
• Cost
• Schedule
• Customer satisfaction
• Quality (functionality/usability/maintainability/
  )

6
Risks vs. Concerns vs. Problems

• A risk is an event/uncertainty which causes a
  failure to execute the plan as expected
• This requires that a plan be in place
• If you dont yet have a plan, you have a concern
• I dont know where were going to get
  developers
• We need to bid X to win, but the true cost is
  XX
• If a risk comes true, then you have a problem
• I didnt get Dan, and he was key to the effort

7
Typical Planning/Risk Timeline
constraints uncertainties
Initial Planning
concerns
plans
refined plans risk management plan
Detailed Planning
concerns risks
Execution
risks
Corrective Action
problems
8
Common Software RisksBarry Boehm, Software Risk
Management

• Changing and uncertain requirements
• Changing and uncertain technologies
• Unrealistic schedules and budgets
• Personnel shortfalls (in numbers, experience,
  morale, etc.)
• Developing the wrong user interface
• Shortfalls in externally provided software
  components
• Straining computer-science capabilities
• Not solving the problem

9
Common Software RisksCapers Jones, Assessment
and Control of Software Risks

• Project Sector Risk Factor Projects at Risk
• MIS Creeping user requirements 80
• Excessive schedule pressure 65
• Low quality 60
• Cost overruns 55
• Inadequate configuration control 50
• Commercial Inadequate user documentation 70
• Low user satisfaction 55
• Excessive time to market 50
• Harmful competitive actions 45
• Litigation expense 30

10
Customer Perspectives of Risk

• Customers want the best possibility of a
  successful development (products that meet
  requirements within the available resources)
• Quality predictability
• Customers can feel threatened by the lack of
  insight
• Less day-to day awareness of status, hidden
  problems
• Generally less technical knowledge
• Adversarial nature of sponsor/contract
  environment
• Customers also have to answer to their sponsors
• May be reluctant to identify risks

11
Project Perspectives of Risk

• Project personnel are also concerned about
  producing a quality project to predictable
  budgets and schedules
• Pride in work, sense of accomplishment
• Satisfying work environment (minimize overtime
  stress)
• Project personnel may see risk management as
  outside their responsibility and/or beyond their
  control
• Project personnel may fear customer/management
  involvement and awareness
• Shoot the messenger
• Micro-management
• Perceived technical inability
• Risk abatement may involve selecting lower risk,
  less technically exciting solutions

12
Risk Management in the CMMI

• Prepare for Risk Management
• Determine Risk Sources and Categories
• Define Risk Parameters
• Establish a Risk Management Strategy
• Identify and Analyze Risks
• Identify Risks
• Evaluate, Classify, and Prioritize Risks
• Mitigate Risks
• Develop Risk Mitigation Plans
• Implement Risk Mitigation Plans

• Institutionalize a Defined Process
• Establish an Organizational Policy
• Establish a Defined Process
• Plan the Process
• Provide Resources
• Assign Responsibility
• Train People
• Manage Configurations
• Identify and Involve Relevant Stakeholders
• Monitor and Control the Process
• Collect Improvement Information
• Objectively Evaluate Adherence
• Review Status with Higher-Level Management

13
Why Manage Risk?

• Since so many things could go wrong (not as you
  expect), it makes sense to treat the planning in
  a probabilistic way
• Set aside extra resources to manage those things
  that
• Are most likely to go wrong
• Cause the worse damage to project success
• Historically, Risk Management has shown great
  value

14
Agenda

• A Definition of Risk
• A Structured Risk Management Process
• CMMI Requirements for Risk Management
• Risk Management Resources

15
Risk Management Process - 1

• Risk Assessment
• Identification - Listing the risks
• Analysis - Determining the probabilities and
  impacts
• Prioritization - Ranking the risks for action
• Risk Control
• Planning - Determining how when to take action
• Resolution - Taking risk mitigation action
• Monitoring - Measuring the outcome
• Risk Reporting

Risk Assessment Identification Analysis
Prioritization
Risk Control Planning Resolution Monitoring
Risk Management
Risk Reporting
16
Risk Management Process - 2

• Risk should be integrated into overall project
  management

Project Planning
Risk Assessment
Risk Planning
Project Control Execution
Risk Resolution
Risk Monitoring
Project Reporting
Risk Reporting
17
Risk Assessment Overview
Risk Assessment Identification Analysis
Prioritization
Risk Control Planning Resolution Monitoring

• Risk Assessment Selecting the risks to be
  managed
• Identification - Listing the risks
• Analysis - Determining the probabilities and
  impacts
• Prioritization - Ranking the risks for action
• Risk assessment should be done systematically at
  the start of a program and repeated at key
  milestones through the program
• Whenever changes occur in requirements,
  constraints, environment gtgt changes in
  probabilities and/or impacts

Risk Management
Risk Reporting
18
Risk Identification - 1
Project characteristics constraints Corporate
experience Project results Templates,
questionnaires
Risk Identification
Risk list
Determines the subset of risksthat warrant
further analysis

• Approaches
• Taxonomy-based risk identification
• Asking experts, using checklists of common risks
• Evaluating program plans for key assumptions and
  drivers
• Key Issues
• Identifying all risks, avoiding limiting the list
• Establishing an open atmosphere
• Ensuring a wide perspective

19
SEI Risk Taxonomyhttp//www.sei.cmu.edu/publicati
ons/documents/93.reports/93.tr.006.html

• Risks are categorized by
• class
• element
• attribute
• Risk taxonomyis intended forsoftware, butcan
  be adaptedfor systemsengineering

20
SEI Taxonomy-Based Questionnaire - 1

• The Questionnaire leads the interviewees through
  the Taxonomy, suggesting areas for further
  discussion
• C. Program Constraints
• 1. Resources
• a. Schedule (Is the schedule inadequate or
  unstable?)
• 144 Is the schedule realistic?(Yes) (144.a)
  Is the estimation method based on historical
  data?(Yes) (144.b) Has the method worked well in
  the past?
• 145 Is there anything for which adequate
  schedule was not planned? Analysis and
  studies QA Training ...

TBQ
21
SEI Taxonomy-Based Questionnaire - 2

• The questionnaire and taxonomy can be used
  several ways
• Manager/lead uses the taxonomy as a checklist
• Identify risks in each category, contributing
  factors
• Manager/lead uses the questionnaire to promote
  thinking through the risks
• Identify risks in each category, contributing
  factors
• Manager/lead distributes taxonomy/questionnaire
  to several people on the projects
• Solicits individual perspectives
• Merges for joint view of risk
• Manager/lead holds group interviews to discuss
  risk
• Uses taxonomy/questionnaire to stimulate
  discussion

TBQ

22
Different Perspectives

• Project Managers
• What can we do?
• Program constraints
• Engineers
• How do we do it?
• Hidden problems in capability culture

• Technical Leads Mgrs.
• How should we do it?
• Historical problems in the application area
• Methods strategies
• Support Functions (SQA, SCM, I T, finance, etc.)
• How well do we do it?
• Effectiveness of methods strategies

23
How Would We Classify the Risks?

• All 5 developers may not be available
• May get assigned developers than expected
• Developed may not be as productive as expected
• The subcontractor may deliver later
• The subcontractor may not deliver what you
  expected
• The requirements may not be complete or
  consistent
• The customer may not have supplied the real
  users requirements

24
Risk Analysis - 1
Risk list Project characteristics
constraints Corporate experience
Risk Analysis
Ranked risk list
Determines the probabilities andimpacts
associated with the risks

• Approaches
• Performance models, cost models, Life Cycle Cost
  Analysis
• Weighted subfactors, sensitivity analyses
• Key Issues
• Determining, classifying the impacts
• Differing perspectives on probabilities
• Clustering all probabilities as low (or high)

25
Risk Analysis - 2

• Risk analysis should clarify the possible
  outcomes and assign values to the probabilities
  and impacts

• Risk area Risk Prob Impact Risk
• Rqmt Stability If requirements change, then High
  X Med Medschedule will slip fixed need
  date prevents meeting users need
• Rqmt Scale If effort is larger than expected, Med
  X Low Low then will not be able to
  staffcausing extensive slips
• Design Perform If throughput rqmts are not Low
  X Med Lowachievable with COTS S/Wthen
  schedule will slip

Risk list
Ranked risk list
Prob High 1gtPgt0.7, Med 0.7gtPgt0.4, Low
0.4gtPgt0.1, None 0.1gtP Impact High gt1M or
slipgt3 months, Med ...
26
Classifying Probability and Impact

• AFSC/AFLC Pamphlet 800-45
• Probability
• Frequent
• Probable
• Improbable
• Impossible
• Impact
• Catastrophic
• Critical
• Marginal
• Negligible

• Commonly-Used Classification
• Probability
• High
• Medium
• Low
• Impact
• Very High
• High
• Moderate
• Low
• Very Low

27
Calculating Risk Exposure
Probability High (3) Medium (2) Low
(1) Very High (5) High (15) High (10) Medium
(5) Impact High (4) High (12) Medium (8) Low
(4) Medium (3) Medium (9) Medium (6) Low
(3) Low (2) Medium (6) Low (4) Low (2) Very Low
(1) Low (3) Low (2) Low (1)
28
Risk Prioritization - 1
Risk Prioritization
Risk control strategies
Ranked risk list Risk management strategy
Determines what general actionswill be taken
for given classes of risks

• Approaches
• Top 10 lists, watchlists
• Risk exposure, risk leverage
• Key Issues
• Tying risk levels to actions
• Focusing the available resources productively
• Integrating with management and metrics

29
Risk Prioritization - 2

• Must decide what generalactions will be taken
  for each class of risks

High Develop risk mitigation plan and
metrics Review monthly with
customer Med Develop risk mitigation plan and
metrics Track in project reviews Low Assign
metrics
1. Requirements stability 2. Staffing
(specialties) 3. Software tools 4. Performance
(xx.xx rqmt) 5. User rqmts for
xxxxx 6. Schedule (IT) 7. Supportability 8. St
orage capacity for xx data 9. Staffing (xxx
subsystem) 10. Program funding stability

• Top 10 list
• The top 10 (or 20, etc.) program risks are
  tracked and reported on in management reviews
• May track all program risks or subsystem risks
  only

30
Risk Control Overview

• Risk Control Taking action to manage the risks
• Planning - Identifying, documenting, and
  communicating the activities and resources used
  to manage risks
• Resolution - Taking action to reduce the risks
  probability or impact
• Monitoring - Measuring and tracking risks
• Risk control is done throughout the program
• (Re-)planning is continuous as some risks are
  mitigated and other risks become more likely or
  gain greater impact

Risk Assessment Identification Analysis
Prioritization
Risk Control Planning Resolution Monitoring
Risk Management
Risk Reporting
31
Risk Planning - 1
Risk Planning
Risk management plan
Risk control strategies Ranked risk list
Identifies, documents, and communicatesthe
activities resources used to manage risks

• Approaches
• Risk Management Plan
• Risk avoidance, transfer, reduction
• Key Issues
• Continual refinement of the plans
• Integration with program plans, software
  development plans
• Tying actions decisions to measurements
  schedules

32
Risk Planning - 2

• Summarize the system
• Summarize the risk managementapproach and
  methods
• List the identified risks priorities
• Describe the risk control actions
• Resolution/mitigation
• Monitoring
• Re-planning
• Identify the resources needed
• Budget, schedule
• Roles, responsibilities
• Interfaces

33
Risk Resolution - 1
Risk control strategies Ranked risk list Risk
management plan
Risk Resolution
Risk actions
Taking actions to mitigate risks

• Approaches
• Risk avoidance
• Risk transfer
• Risk assumption
• Key Issues
• Willingness to invest
• Setting appropriate levels of reserve

34
Risk Resolution - 2

• Risk are composed of( probability of adverse
  outcome ) X ( impact of the outcome )
• To resolve or mitigate the risk, you can
• Reduce the probability
• Reduce the potential impact

35
Risk Resolution Options

• Avoid the risk
• Select another design or implementation strategy
• Eliminate the root cause of the risk
• Transfer the risk from one part of the system to
  another
• Rework project responsibilities/contract
• Change critical path
• Re-do architecture or design
• Assume the risk
• Recognize that no action is appropriate
• Build contingency plans
• Set aside funds or schedule, based on the risk
  exposure

36
Risk Monitoring
Risk control strategies Ranked risk list Risk
management plan Risk actions
Risk Monitoring
Risk metrics Risk decisions
Measuring and tracking risks and using this
data for decision making

• Approaches
• Metrics program
• Risk reports
• Milestone, top 10 tracking
• Corrective action
• Key Issues
• Selecting a predictive set of metrics and
  decision points
• Establishing a cost-effective metrics program
• Integrating metrics into the decision-making
  process

37
Risk Reporting Overview
Risk Assessment Identification Analysis
Prioritization
Risk Control Planning Resolution Monitoring

• Risk Reporting Communicating information
  about the status of risks
• Risk reporting should be done continuously
  throughout the project, as part of the overall
  status

Risk Management
Risk Reporting
38
Risk Reporting
Ranked risk list Risk management plan Risk
actions Risk metrics Risk decisions
Risk Reporting
Risk reports briefings
Communicating risk statusto affected areas of
the program

• Approaches
• Risk reports
• Risk Management Board
• Key Issues
• Identifying the audience
• Summarizing the risk information for the audience
• Adhering to the pre-determined risk actions

39
Risk Reports

• Summarizes metrics and status of risk control
  actions vs. plans
• May be trigger for risk re-planning
• Identifies actions taken, resources used / needed
• Identifies impacts on schedules, resources, other
  program areas
• Key issue is system availability, impact on
  critical path
• Typically reported monthly, may be summarized at
  higher levels
• Status of top 10 list
• Get well plan actions, resources, predicted
  outcome

40
Risk Management Board

• A permanent group that receives risk information
  and assists in decision-making, based on
  multiple perspectives
• Selected to evaluate and advise on the effects
  of the selected risk actions
• May include customers, program management, other
  subsystems, specialty areas, corporate risk
  advisors Customers may be aware of additional
  schedule, resources, specification relief
• Other program areas may help by reallocating
  budgets, staff
• Corporate advisors may provide additional tools,
  technologies, insight from corporate experience
• Typically 5-10 members, with chair and secretary
  / librarian

41
Agenda

• A Definition of Risk
• A Structured Risk Management Process
• CMMI Requirements for Risk Management
• Risk Management Resources

42
Software CMM v1.1

• Risk management was implicit in the SW-CMM
• Part of Software Project Planning, Software
  Project Tracking Oversight, and Integrated
  Software Management

Defect prevention Technology change
management Process change management Quantitative
process management Software quality
management Organization process focus Software
product engineering Organization process
definition Intergroup coordination Training
program Peer reviews Integrated software
management Requirements management Software
subcontract mgmt Software project
planning Software quality assurance Software
project tracking oversight Software
configuration mgmt
LEVEL 5 OPTIMIZING
LEVEL 4 MANAGED
LEVEL 3 DEFINED
LEVEL 2 REPEATABLE
LEVEL 1 INITIAL
43
Risk Management in the Software CMM

• Software Project Planning - Level 2
• Activity 13 The software risks associated with
  the cost, resource, schedule, and technical
  aspects of the project are identified, assessed,
  and documented.
• Software Project Tracking - Level 2
• Activity 10 The software risks associated with
  cost, resource, schedule, and technical aspects
  of the project are tracked.
• Integrated Software Management - Level 3
• Activity 10 The project's software risks are
  identified, assessed, documented, and managed
  according to a documented procedure.

44
CMMI - Staged Representation
Level 5 Optimizing
Organization Innovation Deployment Causal
Analysis and Resolution
Organizational Process Performance Quantitative
Project Management
Level 4 Quantitatively Managed
Requirements Development Technical Solution
Product Integration Verification Validation
Organizational Process Focus Organizational
Process Definition Organizational
Training Integrated Project Management Risk
Management Decision Analysis and Resolution
Level 3Defined
Requirements Management Project Planning Project
Monitoring and Control Supplier Agreement
Management Measurement and Analysis Product
Process Quality Assurance Configuration Management
Level 2 Managed
Level 1Performed
45
For Both Software and Systems Engineering

• Risk Management must be institutionalized at
  Level 3
• Organizational policy
• Define process
• Plan
• Adequate resources
• Assigned responsibility
• Training
• Configuration management
• Identify and involve relevant stakeholders
• Monitor and control
• Collect improvement information
• Objectively evaluate adherence
• Review status with higher-level management

• Risk Management must be implemented at Level 3
• Determine risk sources and categories
• Define risk parameters
• Establish a risk management strategy
• Identify risks
• Evaluate, classify and prioritize risks
• Develop risk mitigation plans
• Implement risk mitigation plans

46
Risk Management in the CMMI

• The purpose of risk management is to identify
  potential problems before they occur, so that
  risk handling activities may be planned and
  invoked as needed across the life cycleto
  mitigate adverse impacts on achieving objectives.
• Required Goals
• Goal 1 Preparation for risk management is
  conducted.
• Goal 2 Risks are identified and analyzed to
  determine their relative importance.
• Goal 3 Risks are handled and mitigated, where
  appropriate, to reduce adverse impacts on
  achieving objectives.
• Goal 4 The process is institutionalized as a
  defined process.

ExpectedImplementation Practices
ExpectedInstitutionalization Practices
47
Expected Implementation Practices

• SP 1.1 Determine Risk Sources and Categories
• Determine risk sources and categories.
• SP 1.2 Define Risk Parameters
• Define the parameters used to analyze and
  classify risks, and the parameters used to
  control the risk management effort.
• SP 1.3 Establish a Risk Management Strategy
• Establish and maintain the strategy and methods
  to be used for risk management.
• SP 2.1 Identify Risks
• Identify and document the risks.
• SP 2.2 Evaluate, Classify, and Prioritize Risks
• Evaluate and classify each identified risk using
  the defined risk categories and parameters, and
  determine its relative priority.
• SP 3.1 Develop Risk Mitigation Plans
• Develop a risk mitigation plan for the most
  important risks to the project, as defined by the
  risk management strategy.
• SP 3.2 Implement Risk Mitigation Plans
• Monitor the status of each risk periodically and
  implement the risk mitigation plan as appropriate.

48
Expected Implementation Practices

• SP 1.1 Determine Risk Sources and Categories
• Determine risk sources and categories.
• SP 1.2 Define Risk Parameters
• Define the parameters used to analyze and
  classify risks, and the parameters used to
  control the risk management effort.
• SP 1.3 Establish a Risk Management Strategy
• Establish and maintain the strategy and methods
  to be used for risk management.
• SP 2.1 Identify Risks
• Identify and document the risks.
• SP 2.2 Evaluate, Classify, and Prioritize Risks
• Evaluate and classify each identified risk using
  the defined risk categories and parameters, and
  determine its relative priority.
• SP 3.1 Develop Risk Mitigation Plans
• Develop a risk mitigation plan for the most
  important risks to the project, as defined by the
  risk management strategy.
• SP 3.2 Implement Risk Mitigation Plans
• Monitor the status of each risk periodically and
  implement the risk mitigation plan as appropriate.

Risk Taxonomy
49
Risk Management Strategy

• The scope used to bound the risk management
  effort
• Methods and tools to be used for risk
  identification, risk analysis, risk mitigation,
  risk monitoring, and communication
• Project-specific sources of risks
• How these risks are to be organized, classified,
  bounded and consolidated
• Global thresholds, parameters and criteria for
  taking action on identified risks
• Risk mitigation techniques to be used, such as
  prototyping, simulation, alternative designs, or
  evolutionary development
• Responsibilities such as control or approval
  levels
• Definition of risk measures to monitor the status
  of the risks
• Time intervals for risk monitoring or
  reassessment
• Typically captured in the Risk Management Plan

50
Expected Institutionalization Practices
1Commitment to Perform

• GP 2.1 (CO 1) Establish an Organizational Policy
• Establish and maintain an organizational policy
  for planning and performing the risk management
  process.

51
Expected Institutionalization Practices
2Ability to Perform

• GP 3.1 (AB 1) Establish a Defined Process
• Establish and maintain the description of a
  defined risk management process.
• GP 2.2 (AB 2) Plan the Process
• Establish and maintain the requirements and
  objectives, and plans for performing the risk
  management process.
• GP 2.3 (AB 3) Provide Resources
• Provide adequate resources for performing the
  risk management process, developing the work
  products and providing the services of the
  process
• GP 2.4 (AB 4) Assign Responsibility
• Assign responsibility and authority for
  performing the process, developing the work
  products, and providing the services of the risk
  management process.
• GP 2.5 (AB 5) Train People
• Train the people performing or supporting the
  risk management process as needed.

52
Expected Institutionalization Practices
3Directing Implementation

• GP 2.6 (DI 1) Manage Configurations
• Place designated work products of the risk
  management process under appropriate levels of
  configuration management.
• GP 2.7 (DI 2) Identify and Involve Relevant
  Stakeholders
• Identify and involve the relevant stakeholders of
  the risk management process as planned.
• GP 2.8 (DI 3) Monitor and Control the Process
• Monitor and control the risk management process
  against the plan and take appropriate corrective
  action.
• GP 3.2 (DI 4) Collect Improvement Information
• Collect work products, measures, measurement
  results, and improvement information derived from
  planning and performing the risk management
  process to support the future use and improvement
  of the organizations processes and process
  assets.

53
Expected Institutionalization Practices
4Verifying Implementation

• GP 2.9 (VE 1) Objectively Evaluate Adherence
• Objectively evaluate adherence of the risk
  management process and the work products and
  services of the process to the applicable
  requirements, objectives, and standards, and
  address noncompliance.
• GP 2.10 (VE 2) Review Status with Higher-Level
  Management
• Review the activities, status, and results of the
  risk management process with higher-level
  management and resolve issues.

54
Other CMMI Process Areas

• Project Planning - Level 2
• SP 2.2 Identify and analyze project risks.
• Project Monitoring Control - Level 2
• SP 1.3 Monitor risks against those identified in
  the project plan.
• Requirements Development - Level 3
• SP 3.4 Analyze requirements with the purpose of
  reducing the life-cycle cost, schedule and risk
  of product development.

55
Agenda

• A Definition of Risk
• A Structured Risk Management Process
• CMMI Requirements for Risk Management
• Risk Management Resources

56
SEI Software Risk Taxonomy

• Software risks are categorized by class, element,
  and attribute
• Taxonomy Based Risk Identification, Marvin Carr,
  et al, CMU/SEI-93-TR-6, 1993

57
SEI Taxonomy-Based Questionnaire

• The Questionnaire leads interviewees through the
  Taxonomy, suggesting areas for exploration of
  risk
• C. Program Constraints
• 1. Resources
• a. Schedule (Is the schedule inadequate or
  unstable?)
• 144 Is the schedule realistic?(Yes) (144.a)
  Is the estimation method based on historical
  data?(Yes) (144.b) Has the method worked well
  in the past?
• 145 Is there anything for which adequate
  schedule was not planned? Analysis and
  studies QA Training ...

58
SEI Team Risk Management

• Principles
• 1. Shared product vision
• 2. Forward-looking search
• for uncertainties
• 3. Open communications
• 4. Value of Individual perception
• 5. Systems perspective
• 6. Integration into program management
• 7. Proactive strategies
• 8. Systematic and adapt-able methodology
• 9. Routine and continuous processes
• Introduction to Team Risk Management (Version
  1.0), Higuera, R., Gluch, D., Dorofee, A.,
  Murphy, L., Walker, A., Williams, C.,
  CMU/SEI-94-SR-001http//www.sei.cmu.edu/publicati
  ons/documents/94.reports/94.sr.001.html

59
References - 1

• DoD Data Analysis Center for Software
  http//www.dacs.dtic.mil/databases/url/key.hts?key
  code270
• Case studies, resources, training, discussion
  groups, software tools, and FAQs related to
  software risk management.
• Software Engineering Institutehttp//www.sei.cmu.
  edu/organization/programs/sepm/risk/risk.mgmt.over
  view.html
• Information relating to risk management, such as
  Risk Management Paradigm, functions of risk
  management, definition, risk versus opportunity.
• Arizona State Universityhttp//www.eas.asu.edu/r
  iskmgmt/
• Introduction to software risk management, risk
  identification questionnaire, and a risk
  management expert system.

60
References - 2

• Department of Computer and Information Science at
  Linköpings Universitethttp//www.ida.liu.se/labs/
  aslab/people/joaka/risk_bib.html
• Compilation of software risk management articles
  by Barry Boehm, R.N. Charette, R. Fairle, et. al.
  
• European Software Institutehttp//www.esi.es/Info
  rmation/Collections/SoftRisk/tools.html
• Tools to risk track, Risk Management tutorial.
• Software Program Managers Networkhttp//www.spmn.
  com
• Risk Radar Tool, resources, presentations.
• NASA GRC Risk Management Officehttp//tkurtz.grc.
  nasa.gov/srqa/
• Resources and guidebooks.

61
Books - 1

• Assessment and Control of Software Risks (Yourdon
  Press Computing), by Capers Jones
• Managing Risk Methods for Software Systems
  Development, by Elaine M. Hall Ph.D.
• Program Risk Management A Guide to Managing
  Project Risks and Opportunities, by R. Max
  Wideman (Editor), Rodney J. Dawson
• Practical Risk Assessment for Project Management,
  by Stephen Grey

62
Books - 2

• Project Risk Management Processes, Techniques
  and Insights, by C. B. Chapman, Stephen Ward,
  Steven Ward
• Software Engineering Risk Management, by Dale
  Walter Karolak
• Software Engineering Risk Analysis and
  Management, by Robert N. Charette, Ph. D.
• Software Risk Management, Barry Boehm, Ph. D.
• Risk Management Concepts and Guidance, by Carl
  L. Pritchard (Editor)

63
Tools

• Risk Radar -- Software Program Managers
  Networkhttp//www.spmn.com/rsktrkr.html
• Risk management database to help project managers
  identify, prioritize, and communicate project
  risks
• RiskTrak - Risk Services Technologyhttp//www.r
  isktrak.com/
• Allows an entire project team or organization to
  view, track, analyze and report on risks in real
  time
• CORA Cost Of Risk Analysis Systemhttp//www.ist-
  usa.com/aboutcora.htm
• Software-based risk management system

64
Conclusion

• Risk Management must be institutionalized at
  Level 3
• Organizational policy
• Define process
• Plan
• Adequate resources
• Assigned responsibility
• Training
• Configuration management
• Identify and involve relevant stakeholders
• Monitor and control
• Collect improvement information
• Objectively evaluate adherence
• Review status with higher-level management

• Risk Management must be implemented at Level 3
• Determine risk sources and categories
• Define risk parameters
• Establish a risk management strategy
• Identify risks
• Evaluate, classify and prioritize risks
• Develop risk mitigation plans
• Implement risk mitigation plans