1. Complying with the CMMI Requirements for Risk Management
Rick Hefner, TRW
Southern California SPIN 28 September 2001
The new Capability Maturity Model Integration (CMMI) model has elevated risk management
to a complete process area. This is a significant change for those organizations that
currently use the CMM for Software. The purpose of this presentation is to discuss the
implications of this change, review the new requirements for risk management, and identify
resources that can be used to implement a practical and effective risk management process.
The purpose of risk management is to identify potential problems before they occur, to
mitigate adverse impacts on achieving objectives. Risk management is a continuous,
forward-looking process, integral to both business and technical management. It
encompasses defining a risk management strategy, identifying and analyzing risks, and
developing and implementing risk mitigation plans.
In the Software CMM v1.1, at Maturity Level 2, projects identified, assessed, documented,
and tracked software risks. At Maturity Level 3, projects were expected to actively manage
the software risks in a more proactive and integrated fashion. In the CMMI maturity model,
risk management has been elevated to a process area, with a full set of required goals and
expected practices that apply to software and systems engineering. In addition to specific
project activities, risk management must be institutionalized through written organizational
policies, plans, allocated resources, assigned responsibilities, training, configuration
management of work products, quality audits, and management reviews.
In current industry practice, many software projects give lip service to risk management by
listing a vague set of nonspecific risks (e.g., inability to meet schedule). Projects often fail to
identify or quantify software-specific risks or mitigation plans, or to continuously manage
them throughout the project life cycle. Often, practitioners view risk management as a
systems engineering function, outside of software's responsibility.
Some organizations have already reaped the benefits of a mature, proactive, software risk
management process. Resources include the SEI's Software Risk Taxonomy and Team Risk
Management process, the Software Project Manager Network's Risk Radar tool, and
numerous books and training courses. This presentation will discuss these, and other
industry best-practices for risk management.

2. Hefner - Complying with the CMMI Requirements for Risk Management
Agenda
A Definition of Risk
A Structured Risk Management Process
CMMI Requirements for Risk Management
Risk Management Resources
Hefner - Complying with the CMMI Requirements for Risk Management

3. Hefner - Complying with the CMMI Requirements for Risk Management
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
Project planning & tracking
Measurement & metrics
Process improvement activities (project & corporate)
Sponsor/contractual & acquisition constraints
Hefner - Complying with the CMMI Requirements for Risk Management

4. Hefner - Complying with the CMMI Requirements for Risk Management
What is a Risk?
You’ve carefully planned out a project
The customer supplied you the user’s 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 user’s requirements
Etc….
Hefner - Complying with the CMMI Requirements for Risk Management

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/…)
Hefner - Complying with the CMMI Requirements for Risk Management

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 don’t yet have a plan, you have a concern
“I don’t know where we’re 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 didn’t get Dan, and he was key to the effort”
Hefner - Complying with the CMMI Requirements for Risk Management

7. Typical Planning/Risk Timeline
constraints
uncertainties
concerns
Initial Planning
plans
refined plans
risk management plan
Detailed
Planning
concerns
risks
Execution
risks
Corrective Action
problems
Hefner - Complying with the CMMI Requirements for Risk Management

8. Common Software Risks Barry 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
Hefner - Complying with the CMMI Requirements for Risk Management

9. Hefner - Complying with the CMMI Requirements for Risk Management
Common Software Risks Capers 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%
Hefner - Complying with the CMMI Requirements for Risk Management

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”
Hefner - Complying with the CMMI Requirements for Risk Management

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
Hefner - Complying with the CMMI Requirements for Risk Management

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
Hefner - Complying with the CMMI Requirements for Risk Management

13. Historically, Risk Management has shown great value
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
Hefner - Complying with the CMMI Requirements for Risk Management

14. Hefner - Complying with the CMMI Requirements for Risk Management
Agenda
A Definition of Risk
A Structured Risk Management Process
CMMI Requirements for Risk Management
Risk Management Resources
Hefner - Complying with the CMMI Requirements for Risk Management

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
Hefner - Complying with the CMMI Requirements for Risk Management

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
Hefner - Complying with the CMMI Requirements for Risk Management

17. Risk Assessment Overview
• 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 >> changes in probabilities and/or impacts
Risk Management
Risk Reporting
Hefner - Complying with the CMMI Requirements for Risk Management

18. Determines the subset of risks that warrant further analysis
Risk Identification - 1
Project characteristics & constraints
Corporate experience
Project results
Templates, questionnaires
Risk Identification
Risk list
Determines the subset of risks that 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
Hefner - Complying with the CMMI Requirements for Risk Management

19. Hefner - Complying with the CMMI Requirements for Risk Management
SEI Risk Taxonomy
Risks are categorized by
class
element
attribute
Risk taxonomy is intended for software, but can be adapted for systems engineering
Hefner - Complying with the CMMI Requirements for Risk Management

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
Hefner - Complying with the CMMI Requirements for Risk Management

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
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
Hefner - Complying with the CMMI Requirements for Risk Management

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
Hefner - Complying with the CMMI Requirements for Risk Management

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 user’s requirements
Hefner - Complying with the CMMI Requirements for Risk Management

24. Determines the probabilities and impacts associated with the risks
Risk Analysis - 1
Risk list
Project characteristics & constraints
Corporate experience
Risk Analysis
Ranked risk list
Determines the probabilities and impacts 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)
Hefner - Complying with the CMMI Requirements for Risk Management

25. Hefner - Complying with the CMMI Requirements for Risk Management
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 = Med schedule 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 staff causing extensive slips
Design Perform If throughput rqmts are not Low X Med = Low achievable with COTS S/W; then schedule will slip
Risk list
Ranked risk list
†Prob – High: 1>P>0.7, Med: 0.7>P>0.4, Low: 0.4>P>0.1, None: 0.1>P Impact – High: >$1M or slip>3 months, Med: ...
Hefner - Complying with the CMMI Requirements for Risk Management

26. Classifying Probability and Impact
AFSC/AFLC Pamphlet
Probability
Frequent
Probable
Improbable
Impossible
Impact
Catastrophic
Critical
Marginal
Negligible
Commonly-Used Classification
Probability
High
Medium
Low
Impact
Very High
Moderate
Very Low
Hefner - Complying with the CMMI Requirements for Risk Management

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)
Hefner - Complying with the CMMI Requirements for Risk Management

28. Hefner - Complying with the CMMI Requirements for Risk Management
Risk Prioritization - 1
Risk Prioritization
Ranked risk list
Risk management strategy
Risk control strategies
Determines what general actions will 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
Hefner - Complying with the CMMI Requirements for Risk Management

29. Hefner - Complying with the CMMI Requirements for Risk Management
Risk Prioritization - 2
Must decide what general actions 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 (I&T)
7. Supportability
8. Storage 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
Hefner - Complying with the CMMI Requirements for Risk Management

30. Hefner - Complying with the CMMI Requirements for Risk Management
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
Hefner - Complying with the CMMI Requirements for Risk Management

31. Hefner - Complying with the CMMI Requirements for Risk Management
Risk Planning - 1
Risk Planning
Risk management plan
Risk control strategies
Ranked risk list
Identifies, documents, and communicates the 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
Hefner - Complying with the CMMI Requirements for Risk Management

32. Hefner - Complying with the CMMI Requirements for Risk Management
Risk Planning - 2
Summarize the system
Summarize the risk management approach 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
Hefner - Complying with the CMMI Requirements for Risk Management

33. Taking actions to mitigate risks
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
Hefner - Complying with the CMMI Requirements for Risk Management

34. Hefner - Complying with the CMMI Requirements for Risk Management
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
Hefner - Complying with the CMMI Requirements for Risk Management

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
Hefner - Complying with the CMMI Requirements for Risk Management

36. Measuring and tracking risks and using this data for decision making
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
Hefner - Complying with the CMMI Requirements for Risk Management

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
Hefner - Complying with the CMMI Requirements for Risk Management

38. Communicating risk status to affected areas of the program
Risk Reporting
Ranked risk list
Risk management plan
Risk actions
Risk metrics
Risk decisions
Risk Reporting
Risk reports & briefings
Communicating risk status to 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
Hefner - Complying with the CMMI Requirements for Risk Management

39. Hefner - Complying with the CMMI Requirements for Risk Management
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
Hefner - Complying with the CMMI Requirements for Risk Management

40. Hefner - Complying with the CMMI Requirements for Risk Management
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
Hefner - Complying with the CMMI Requirements for Risk Management

41. Hefner - Complying with the CMMI Requirements for Risk Management
Agenda
A Definition of Risk
A Structured Risk Management Process
CMMI Requirements for Risk Management
Risk Management Resources
Hefner - Complying with the CMMI Requirements for Risk Management

42. Hefner - Complying with the CMMI Requirements for Risk Management
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
Hefner - Complying with the CMMI Requirements for Risk Management

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.
Hefner - Complying with the CMMI Requirements for Risk Management

44. CMMI - Staged Representation
Level 5
Optimizing
Organization Innovation & Deployment
Causal Analysis and Resolution
Level 4
Quantitatively Managed
Organizational Process Performance
Quantitative Project Management
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 3 Defined
Requirements Management
Project Planning
Project Monitoring and Control
Supplier Agreement Management
Measurement and Analysis
Product & Process Quality Assurance
Configuration Management
Level 2
Managed
Level 1 Performed
Hefner - Complying with the CMMI Requirements for Risk Management

45. For Both Software and Systems Engineering
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
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
Hefner - Complying with the CMMI Requirements for Risk Management

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 cycle to 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.
Expected Implementation
Practices
Expected Institutionalization
Practices
Hefner - Complying with the CMMI Requirements for Risk Management

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.
Hefner - Complying with the CMMI Requirements for Risk Management

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
Hefner - Complying with the CMMI Requirements for Risk Management

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
Hefner - Complying with the CMMI Requirements for Risk Management

50. Expected Institutionalization Practices – 1 Commitment 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.
Hefner - Complying with the CMMI Requirements for Risk Management

51. Expected Institutionalization Practices – 2 Ability 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.
Hefner - Complying with the CMMI Requirements for Risk Management

52. Expected Institutionalization Practices – 3 Directing 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 organization’s processes and process assets.
Hefner - Complying with the CMMI Requirements for Risk Management

53. Expected Institutionalization Practices – 4 Verifying 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.
Hefner - Complying with the CMMI Requirements for Risk Management

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.
Hefner - Complying with the CMMI Requirements for Risk Management

55. Hefner - Complying with the CMMI Requirements for Risk Management
Agenda
A Definition of Risk
A Structured Risk Management Process
CMMI Requirements for Risk Management
Risk Management Resources
Hefner - Complying with the CMMI Requirements for Risk Management

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
Hefner - Complying with the CMMI Requirements for Risk Management

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 ...
Hefner - Complying with the CMMI Requirements for Risk Management

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
Hefner - Complying with the CMMI Requirements for Risk Management

59. Hefner - Complying with the CMMI Requirements for Risk Management
References - 1
DoD Data Analysis Center for Software
Case studies, resources, training, discussion groups, software tools, and FAQs related to software risk management.
Software Engineering Institute
Information relating to risk management, such as: Risk Management Paradigm, functions of risk management, definition, risk versus opportunity.
Arizona State University
Introduction to software risk management, risk identification questionnaire, and a risk management expert system.
Hefner - Complying with the CMMI Requirements for Risk Management

60. Hefner - Complying with the CMMI Requirements for Risk Management
References - 2
Department of Computer and Information Science at Linköpings Universitet
Compilation of software risk management articles by Barry Boehm, R.N. Charette, R. Fairle, et. al.
European Software Institute
Tools to risk track, Risk Management tutorial.
Software Program Managers Network
Risk Radar Tool, resources, presentations.
NASA GRC Risk Management Office
Resources and guidebooks.
Hefner - Complying with the CMMI Requirements for Risk Management

61. Hefner - Complying with the CMMI Requirements for Risk Management
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
Hefner - Complying with the CMMI Requirements for Risk Management

62. Hefner - Complying with the CMMI Requirements for Risk Management
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)
Hefner - Complying with the CMMI Requirements for Risk Management

63. Hefner - Complying with the CMMI Requirements for Risk Management
Tools
Risk Radar -- Software Program Managers Network
Risk management database to help project managers identify, prioritize, and communicate project risks
RiskTrak - Risk Services & Technology
Allows an entire project team or organization to view, track, analyze and report on risks in real time
CORA: Cost Of Risk Analysis System
Software-based risk management system
Hefner - Complying with the CMMI Requirements for Risk Management

64. Hefner - Complying with the CMMI Requirements for Risk Management
Conclusion
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
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
Hefner - Complying with the CMMI Requirements for Risk Management