simranjeet kaur1 fundamentals of software risk management
DESCRIPTION
Simranjeet Kaur3 Software Risk Management Risk Management is a practice with processes, methods, and tools for managing risks in a project.TRANSCRIPT
![Page 1: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/1.jpg)
Simranjeet Kaur 1
Fundamentalsof
Software Risk Management
![Page 2: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/2.jpg)
Simranjeet Kaur 2
Why do software projects go wrong?
• Inadequate understanding of customer needs• Poor requirements documents• Poor requirements management• Poor or no architecture/design• Code first and ask questions later• Poorly understood legacy design/code• No peer reviews to catch problems early• Inexperienced or incapable personnel• Ineffective testing – misses serious defects• …
![Page 3: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/3.jpg)
Simranjeet Kaur 3
Software Risk Management
Risk Management is a practice with processes, methods, and tools for managing risks in a project.
![Page 4: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/4.jpg)
Simranjeet Kaur 4
What is risk?
A risk is a possibility of loss.
Undesirable outcome.
Missed opportunity.
![Page 5: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/5.jpg)
Simranjeet Kaur 5
Anatomy of a risk
Risk
Probability of occurrence
Consequence: size of loss
![Page 6: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/6.jpg)
Simranjeet Kaur 6
Classification of software risks• Software Project Risks
– Resource constraints, external interfaces, supplier relationships, nonperforming vendors, internal politics, interteam/intergroup coordination problems, inadequate funding.
• Software Process Risks– Undocumented software process, lack of effective peer reviews, no
defect prevention, poor design process, poor requirements management, ineffective planning.
• Software Product Risks– Lack of domain expertise, complex design, poorly defined interfaces,
poorly understood legacy system(s), vague or incomplete requirements.
![Page 7: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/7.jpg)
Simranjeet Kaur 7
The Risk Management ProcessIdentify risks
Resolve risks
Analyze risks
Plan for risks
Track risks
Learn about risks RiskKnowledge
Base
![Page 8: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/8.jpg)
Simranjeet Kaur 8
Identification: Discovery
TeamBrainstorming
RiskKnowledge
Base
Walkthroughs
Spurious
![Page 9: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/9.jpg)
Simranjeet Kaur 9
Identification: Quantification
Risk Exposure = Probability x Consequence
![Page 10: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/10.jpg)
Simranjeet Kaur 10
Calculating Risk Exposure
Factor P C RELate delivery from COTS vendor ACME 0.25 28 days 7 days
ACME API integration delay 0.6 15 days 9 days
Additional unit testing needed; 3% more classes than first estimated
0.9 20 days 18 days
Beta test group reports that they may not be able to fit us into their pipeline until May 1 instead of April 1
0.5 30 days 15 days
TOTAL RISK EXPOSURE 49 days
Note: For simplicity, all risk consequences are calendar time delays.
![Page 11: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/11.jpg)
Simranjeet Kaur 11
Perceived ProbabilityAlmost certainlyHighly likelyVery good chanceProbableLikelyProbablyWe believeBetter than evenWe doubtImprobableUnlikelyProbably notLittle chanceAlmost no chanceHighly unlikelyChances are slight
0 .1 .2 .3 .4 .5 .6 .7 .8 .9 1.0
Adapted from Managing Risk: Methods for Software Systems Development by Elaine M. Hall, Addison-Wesley 1998
![Page 12: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/12.jpg)
Simranjeet Kaur 12
Why quantify risk– Allows solution ideas to be evaluated more critically
– Encourages design awareness of risk
– Allows feedback on risks we missed
– Allows feedback on impact of risks we anticipated
– Allows us to allocate resources to deal with risks
– Allows us to determine whether a risk is acceptable
![Page 13: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/13.jpg)
Simranjeet Kaur 13
Identification: Documentation
HeaderAssessmentAction Plan
TrackingResolution
Project Name of project
Date Date of entry
Risk name Name of risk
Risk category Type of risk
Probability Likelihood of occurrence
Consequence Severity of impact
Originator Who reported this risk
Phase/activity Where in software process
WBS Element WBS relationship
Adapted from Managing Risk: Methods for Software Systems Development by Elaine M. Hall, Addison-Wesley 1998
![Page 14: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/14.jpg)
Simranjeet Kaur 14
Identification: CommunicationNotify all affected stakeholders:
•Customers•Project/Program Manager•Fellow Team Members•Management•Marketing•Sales•Customer Support•Finance•Quality Assurance•SEPG•…
![Page 15: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/15.jpg)
Simranjeet Kaur 15
Analysis of risks: Questions
– How severe is the consequence?– How likely is the occurrence?– Is the risk exposure acceptable?– How soon must the risk be dealt with?– What is causing the risk?– Are there similarities between risks?– Are there dependency relationships?– What are the risk drivers?
![Page 16: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/16.jpg)
Simranjeet Kaur 16
Analysis of risks: Activities•Grouping
– Eliminate redundant risks; Combine related risks; Link dependent risks
•Determining risk drivers– Underlying factors that affect severity of consequence– May affect estimation of probability, consequence, risk exposure– Increases understanding of how risks can be mitigated
•Ranking– Order of likelihood, consequence, exposure, time frame
•Determining root causes (sources of risk)– Old-fashion root cause analysis,– Identify common root causes
![Page 17: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/17.jpg)
Simranjeet Kaur 17
Analysis: Documentation
HeaderAssessmentAction Plan
TrackingResolution
Adapted from Managing Risk: Methods for Software Systems Development by Elaine M. Hall, Addison-Wesley 1998
Statement Brief description of risk
Context When, where, how, why
Analysis Impact on project
![Page 18: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/18.jpg)
Simranjeet Kaur 18
Planning: Resolution Strategies• Risk Avoidance
– Prevent the risk from occurring, reduce probability to zero
• Risk Protection– Reduce the probability and/or consequence of the risk before it happens
• Risk Reduction– Reduce the probability and/or consequence of the risk after it happens
• Risk Research– Obtain more information to eliminate or reduce uncertainty
• Risk Reserves– Use previously allocated schedule or budget slack
• Risk Transfer– Rearrange things to shift risk elsewhere (to another group, for example)
![Page 19: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/19.jpg)
Simranjeet Kaur 19
Planning: Activities• Specify scenarios
– How would we be able to tell it is really happening?
• Define quantified threshold for early warning– What to monitor, when we consider the risk to be happening
• Develop resolution alternatives– Ways to eliminate, mitigate or handle the risk
• Select resolution approach– What has the best ROI?
• Specify risk action plan– Document decisions
![Page 20: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/20.jpg)
Simranjeet Kaur 20
Planning/Tracking: Documentation
HeaderAssessmentAction Plan
TrackingResolution
Scenario What would happen?
Indicator Metric to be monitored
Trigger condition Value indicating risk scenario
Checkpoint When/where to check metric
Resolution strategy How we will handle the risk
Action plan Concrete action plan
![Page 21: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/21.jpg)
Simranjeet Kaur 21
Tracking• Monitor risk scenarios
– Watch for signs of a risk scenario occurring
• Compare indicators to trigger conditions– Watch indicator metrics – do they satisfy trigger conditions?
• Notify stakeholders– Let stakeholders know the risk is happening; execute action plan
• Collect statistics– Update risk database
![Page 22: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/22.jpg)
Simranjeet Kaur 22
Resolution• Acknowledge receipt of notification
– Let stakeholders know you are “on the ball”– Indicate response time– Determine accountability/ownership
• Execute action plan– Improvise, adapt, overcome– Wanted: common sense
• Provide continuous updates– Let stakeholders know your progress in resolving the risk
• Collect statistics– Update risk database
![Page 23: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/23.jpg)
Simranjeet Kaur 23
Resolution: Documentation
HeaderAssessmentAction Plan
TrackingResolution
Software Engineer Signature
Quality Engineer Signature
Project Manager Signature
Marketing Manager Signature
![Page 24: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/24.jpg)
Simranjeet Kaur 24
Risk Management Capability
1: Risks ignored or only tracked in an ad-hoc fashion
2: Risks are usually recorded, tracked and handled as they are discovered
3: Risks systematically quantified, analyzed, planned, tracked and resolved
5: Risk statistics used to make organizational/process improvements
4: Quantified analysis used to determine resolution cost/benefit for project
![Page 25: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/25.jpg)
Simranjeet Kaur 25
Requirements Capture
Design/Select Architecture
High-level evolutionary plan
Select and plannext step
Execute planned step
Deliver to real users
Evaluate feedback
“micro-projects”
Evolutionary Delivery
Identify
Analyze
Plan
Track
Resolve
Learn
![Page 26: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/26.jpg)
Simranjeet Kaur 26
Learning from risks• Post mortem:
– What were the unanticipated risks?– What was the actual severity of consequence?– What resolution strategies worked well/not so well?– What types of risks could we
• prevent or transfer?• protect ourselves from or reduce?• handle only by allocating reserves?
• Action:– What are the preventative measures we can take in the future?– What can the SEPG do?– Are there significant vendor/partner performance problems?– What can we share with other project teams?
![Page 27: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/27.jpg)
Simranjeet Kaur 27
Risk Management Infrastructure
CommonRisks
Checklists
RiskDatabase
WithStatistics
StandardRisk
TemplateRisk
RankingTemplate
RiskMgt.Plan
Template
![Page 28: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/28.jpg)
Simranjeet Kaur 28
Opportunity ManagementIdentify opportunity
Take advantageof opportunity
Analyze opportunity
Plan for opportunity
Track opportunity
Learn about opportunities
OpportunityKnowledge
Base
![Page 29: Simranjeet Kaur1 Fundamentals of Software Risk Management](https://reader034.vdocuments.site/reader034/viewer/2022052606/5a4d1ada7f8b9ab0599744db/html5/thumbnails/29.jpg)
Simranjeet Kaur 29
Questions?