Complying with the CMMI Requirements for Risk Management - PowerPoint PPT Presentation

Loading...

PPT – Complying with the CMMI Requirements for Risk Management PowerPoint presentation | free to download - id: e2c39-MjlmM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Complying with the CMMI Requirements for Risk Management

Description:

Taxonomy-based risk identification. Asking experts, using checklists ... SEI Taxonomy-Based Questionnaire - 1 ... Manager/lead uses the taxonomy as a checklist ... – PowerPoint PPT presentation

Number of Views:226
Avg rating:3.0/5.0
Slides: 65
Provided by: RickH50
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Complying with the CMMI Requirements for Risk Management


1
Complying with the CMMI Requirements for Risk
Management
  • Rick Hefner, TRW
  • rick.hefner_at_trw.com 310.812.7290
  • Southern California SPIN 28 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 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

9
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

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 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

19
SEI Risk Taxonomy http//www.sei.cmu.edu/publicati
ons/documents/93.reports/93.tr.006.html
  • Risks are categorized by
  • class
  • element
  • attribute
  • Risk taxonomy is intended for software, but can
    be adapted for systems engineering

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 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)

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 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 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 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

29
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 (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 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

32
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

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 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

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 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
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 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
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
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.

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.

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 organizations processes and process
    assets.

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.

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-001 http//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 Institute http//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 University http//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 Universitet http//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 Institute http//www.esi.es/Info
    rmation/Collections/SoftRisk/tools.html
  • Tools to risk track, Risk Management tutorial.
  • Software Program Managers Network http//www.spmn.
    com
  • Risk Radar Tool, resources, presentations.
  • NASA GRC Risk Management Office http//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
    Network http//www.spmn.com/rsktrkr.html
  • Risk management database to help project managers
    identify, prioritize, and communicate project
    risks
  • RiskTrak - Risk Services Technology http//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 System http//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
About PowerShow.com