complying with the cmmi requirements for risk management rick hefner, trw [email protected]...

Complying with the CMMI Requirements for Risk Management

Rick Hefner, TRW

[email protected]

Southern California SPIN28 September 2001

TRWHefner - Complying with the CMMI Requirements for Risk Management2

Agenda

• A Definition of Risk

• A Structured Risk Management Process

• CMMI Requirements for Risk Management

• Risk Management Resources


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


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


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


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”


Typical Planning/Risk Timeline

Initial Planning

DetailedPlanning

Execution

concerns

constraintsuncertainties

plans

concernsrisks

risks

refined plansrisk management plan

Corrective Actionproblems


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


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%


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”


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


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


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


Agenda






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 Control• Planning

• Resolution• Monitoring

Risk Assessment• Identification

• Analysis• Prioritization

Risk Reporting

Risk Management


Risk Management Process - 2

• Risk should be integrated into overall project management

Project Planning

Project Control& Execution

Project Reporting

Risk Assessment

Risk Planning

Risk Resolution

Risk Monitoring

Risk Reporting


Risk Assessment Overview

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

Risk Management


Risk Identification - 1

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

Determines the subset of risksthat warrant further analysis

Risk Identification

Project characteristics& constraints

Corporate experienceProject resultsTemplates, questionnaires

Risk list


SEI Risk Taxonomyhttp://www.sei.cmu.edu/publications/documents/93.reports/93.tr.006.html

• Risks are categorized by– class– element– attribute

• Risk taxonomyis intended forsoftware, butcan be adaptedfor systemsengineering

B. Development Environment

1. Development Process a. Formality b. Suitability c. Process Control d. Familiarity e. Product Control

2. Development System a. Capacity b. Suitability c. Usability d. Familiarity e. Reliability f. System Support g. Deliverability

3. Management Process a. Planning b. Project Organization c. Management Experience d. Program Interfaces

4. Management Methods a. Monitoring b. Personnel Management c. Quality Assurance d. Configuration Management

5. Work Environment a. Quality Attitude b. Cooperation c. Communication d. Morale

A. Product Engineering

1. Requirements a. Stability b. Completeness c. Clarity d. Validity e. Feasibility f. Precedent g. Scale

2. Design a. Functionality b. Difficulty c. Interfaces d. Performance e. Testability f. Hardware g. Non-Developmental Software

3. Code and Unit Test a. Feasibility b. Testing c. Coding/Implementation

4. Integration and Test a. Environment b. Product c. System

5. Engineering Specialties a. Maintainability b. Reliability c. Safety d. Security e. Human Factors f. Specifications

C. Program Constraints

1. Resources a. Schedule b. Staff c. Budget d. Facilities

2. Contract a. Type of Contract b. Restrictions c. Dependencies

3. Program Interfaces a. Customer b. Associate Contractors c. Subcontractors d. Prime Contractor e. Corporate Management f. Vendors g. Politics


SEI Taxonomy-Based Questionnaire - 1

• The Questionnaire leads the interviewees through the Taxonomy, suggesting areas for further discussion

C. Program Constraints1. 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


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


















Different Perspectives

Project ManagersWhat can we do?– Program constraints

EngineersHow 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


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


















Risk Analysis - 1

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)

Determines the probabilities andimpacts associated with the risks

Risk Analysis

Risk listProject characteristics

& constraintsCorporate experience

Ranked risk list


Risk Analysis - 2

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/W;then schedule will slip

Risk list

Ranked risk list

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

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


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


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)

Calculating Risk Exposure


Risk Prioritization - 1

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

Determines what general actionswill be taken for given classes of risks

Risk PrioritizationRanked risk listRisk management strategy

Risk control strategies


Risk Prioritization - 2

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

1.Requirements stability2.Staffing (specialties)3.Software tools4.Performance (xx.xx rqmt)5.User rqmts for xxxxx6.Schedule (I&T)7.Supportability8.Storage capacity for xx data9.Staffing (xxx subsystem)10.Program funding stability

1.Requirements stability2.Staffing (specialties)3.Software tools4.Performance (xx.xx rqmt)5.User rqmts for xxxxx6.Schedule (I&T)7.Supportability8.Storage capacity for xx data9.Staffing (xxx subsystem)10.Program funding stability

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

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


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 Reporting

Risk Management


Risk Planning - 1

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

Identifies, documents, and communicatesthe activities & resources used to manage risks

Risk PlanningRisk management planRisk control strategies

Ranked risk list


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


Risk Resolution - 1

Approaches– Risk avoidance– Risk transfer– Risk assumption

Key Issues– Willingness to invest– Setting appropriate levels of reserve

Taking actions to mitigate risks

Risk ResolutionRisk actions

Risk control strategiesRanked risk listRisk management plan


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


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


Risk Monitoring

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

Measuring and tracking risks and using this data for decision making

Risk MonitoringRisk control strategiesRanked risk listRisk management planRisk actions

Risk metricsRisk decisions


Risk Reporting Overview

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

Risk Management


Risk Reporting

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

Communicating risk statusto affected areas of the program

Risk ReportingRanked risk listRisk management planRisk actionsRisk metricsRisk decisions

Risk reports & briefings


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


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


Agenda






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 preventionTechnology change managementProcess change management

Quantitative process managementSoftware quality management

Organization process focus Software product engineeringOrganization process definition Intergroup coordination Training program Peer reviewsIntegrated software management

Requirements management Software subcontract mgmtSoftware project planning Software quality assuranceSoftware project tracking & oversight Software configuration mgmt

LEVEL 5OPTIMIZING

LEVEL 4MANAGED

LEVEL 3DEFINED

LEVEL 2REPEATABLE

LEVEL 1INITIAL


Risk Management in the Software CMM

Software Project Planning - Level 2Activity 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 2Activity 10 The software risks associated with cost, resource,

schedule, and technical aspects of the project are tracked.

Integrated Software Management - Level 3Activity 10 The project's software risks are identified, assessed,

documented, and managed according to a documented procedure.


CMMI - Staged Representation

Requirements ManagementProject PlanningProject Monitoring and ControlSupplier Agreement Management Measurement and Analysis Product & Process Quality AssuranceConfiguration Management

Requirements DevelopmentTechnical Solution Product IntegrationVerification Validation Organizational Process FocusOrganizational Process DefinitionOrganizational TrainingIntegrated Project ManagementRisk Management Decision Analysis and Resolution

Organizational Process Performance Quantitative Project Management

Organization Innovation & Deployment Causal Analysis and Resolution

Level 2Managed

Level 3Defined

Level 4Quantitatively Managed

Level 5Optimizing

Level 1Performed


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


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

ExpectedImplementationPractices

ExpectedInstitutionalizationPractices


Expected Implementation Practices

SP 1.1 Determine Risk Sources and CategoriesDetermine risk sources and categories.

SP 1.2 Define Risk ParametersDefine 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 StrategyEstablish and maintain the strategy and methods to be used for risk management.

SP 2.1 Identify RisksIdentify and document the risks.

SP 2.2 Evaluate, Classify, and Prioritize RisksEvaluate and classify each identified risk using the defined risk categories and parameters, and determine its relative priority.

SP 3.1 Develop Risk Mitigation PlansDevelop 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 PlansMonitor the status of each risk periodically and implement the risk mitigation plan as appropriate.


Expected Implementation Practices

SP 1.1 Determine Risk Sources and CategoriesDetermine risk sources and categories.

SP 1.2 Define Risk ParametersDefine 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 StrategyEstablish and maintain the strategy and methods to be used for risk management.

SP 2.1 Identify RisksIdentify and document the risks.

SP 2.2 Evaluate, Classify, and Prioritize RisksEvaluate and classify each identified risk using the defined risk categories and parameters, and determine its relative priority.

SP 3.1 Develop Risk Mitigation PlansDevelop 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 PlansMonitor the status of each risk periodically and implement the risk mitigation plan as appropriate.

Risk Taxonomy


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


Expected Institutionalization Practices – 1Commitment to Perform

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


Expected Institutionalization Practices – 2Ability to Perform

GP 3.1 (AB 1) Establish a Defined ProcessEstablish and maintain the description of a defined risk management process.

GP 2.2 (AB 2) Plan the ProcessEstablish and maintain the requirements and objectives, and plans for performing the risk management process.

GP 2.3 (AB 3) Provide ResourcesProvide 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 ResponsibilityAssign 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 PeopleTrain the people performing or supporting the risk management process as needed.


GP 2.6 (DI 1) Manage ConfigurationsPlace designated work products of the risk management process under appropriate levels of configuration management.

GP 2.7 (DI 2) Identify and Involve Relevant StakeholdersIdentify and involve the relevant stakeholders of the risk management process as planned.

GP 2.8 (DI 3) Monitor and Control the ProcessMonitor and control the risk management process against the plan and take appropriate corrective action.

GP 3.2 (DI 4) Collect Improvement InformationCollect 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.

Expected Institutionalization Practices – 3Directing Implementation


Expected Institutionalization Practices – 4Verifying Implementation

GP 2.9 (VE 1) Objectively Evaluate AdherenceObjectively 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 ManagementReview the activities, status, and results of the risk management process with higher-level management and resolve issues.


Other CMMI Process Areas

Project Planning - Level 2SP 2.2 Identify and analyze project risks.

Project Monitoring & Control - Level 2SP 1.3 Monitor risks against those identified in the project

plan.

Requirements Development - Level 3SP 3.4 Analyze requirements with the purpose of reducing

the life-cycle cost, schedule and risk of product development.


Agenda






















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


SEI Taxonomy-Based Questionnaire

• The Questionnaire leads interviewees through the Taxonomy, suggesting areas for exploration of risk

C. Program Constraints1. 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 ...


Principles1. Shared product vision2. Forward-looking search for uncertainties3. Open communications 4. Value of Individual perception5. Systems perspective6. Integration into program management7. Proactive strategies8. Systematic and adapt-able methodology9. 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/publications/documents/94.reports/94.sr.001.html

SEI Team Risk Management


References - 1

• DoD Data Analysis Center for Software http://www.dacs.dtic.mil/databases/url/key.hts?keycode=270– 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.overview.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/~riskmgmt/ – Introduction to software risk management, risk identification

questionnaire, and a risk management expert system.


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


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


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)


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


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

complying with the cmmi requirements for risk management rick hefner, trw [email protected]...

Documents

software risk management

definition of risk

risk management4

risk management rick

risk management6 risks

hefner complying

risk management2 agenda

uncertain requirements