SlideShare una empresa de Scribd logo
1 de 30
ASQ Section 509 SIG
Practical Risk Management
WELCOME!
 Objectives:
 Review basic definitions
 Take a quick look at some related standards and CMMI
 Process Steps: Integrating a risk management approach into the
project life cycle
 Walk through a sample project to demonstrate risk management
techniques
ASQ Section 509 SIG
Practical Risk Management
What is Risk Management?
‘Risks’ have not happened yet…
‘Risk’ is the probability of an event occurring with the possibility of
derailing project success.
‘Risks’ that are not managed and controlled can have a negative
impact on a project team’s
Deliverables
Budget
Product Quality
ASQ Section 509 SIG
Practical Risk Management
Definitions of Risk
IEEE: The likelihood of an event, hazard, threat, or
situation occurring some time in the future
Definition (ISTQB) - Systematic application of procedures
and practices to the tasks of identifying, analyzing,
prioritizing, and controlling risks
How Do You Define Risks?
ASQ Section 509 SIG
Practical Risk Management
ISO Standards Related to Managing Risks
ISO/ IEC 27002:2013 - Details security policy requirements for protecting
an organization's physical and information technology assets
ISO 31000:2009, Risk management – details a framework and process for
managing risk.
ISO Guide 73:2009, Risk management - details terms and definitions
relating to the management of risk.
ISO/IEC 31010:2009, Risk management – Risk assessment techniques
focuses on risk assessment
ASQ Section 509 SIG
Practical Risk Management
CMMI and Risk Management
Risk management is a project management process area for maturity level
3 organizations.
The purpose of risk management (RSKM) is to identify potential issues or
problems before they occur; and to have planned activities in place and
available to reduce or eliminate the impact of the risk.
For level three organizations, risk management should be an ongoing
integrated process; and will address issues that could possibly have a
negative impact on project deliverables, costs, and objectives.
Source: Software-Quality-Assurance.org is an independent Web Site that presents
information about CMMi
ASQ Section 509 SIG
Practical Risk Management
Consider Levels of Risk Maturity
(1) Not aware of the need for risk management
(2) Organizations are aware of the potential benefits, however
have not implemented process
(3) Built management of risks into routine business processes
(4) Have a risk aware culture
Source: Fundamentals of Risk Management by Paul Hopkin
ASQ Section 509 SIG
Practical Risk Management
Traditional /Waterfall Approach Agile Approach
 Project management focuses on
costs and schedule, and project
goals at a high level.
 Tends not to be a working
document for teams to use.
 Focus is on ‘day to day’ issues
and is managed through
standups, focus groups, and
lessons learned, however there is
no formal risk management
process shared with the team.
When comparing Agile Scrum to Traditional / Waterfall projects,
there is no defined process for risk management
ASQ Section 509 SIG
Practical Risk Management
How do you define risks?
ASQ Section 509 SIG
Practical Risk Management
What’s your experience with regard to risk
management?
Is risk management relevant to your daily
project work?
Track
AnalyzeIdentify Plan
ASQ Section 509 SIG
Practical Risk Management
Discuss the project risks openly Taxonomy Based Questionnaire –
www.sei.cmu.edu/reports/93tr006.
pdf
Conduct interviews, reports Focus on risks unique to project
Use decomposition to identify
risks within the work
breakdown structure
Focus is on undesirable consequence
(events, hazards, threats)
ASQ Section 509 SIG
Practical Risk Management
Identifying Risks
SEI’s Software Development Risk Taxonomy questionnaire can
help facilitate risk identification in a specific area of
software development.
ASQ Section 509 SIG
Practical Risk Management
Identifying Risks
ASQ Section 509 SIG
Practical Risk Management
Identifying Risks
Input Output
Brain storm problems and
issues that can impact
the team’s ability to
deliver quality products
to the customer
Generate an easy to
update risk list for
tracking actions
ASQ Section 509 SIG
Practical Risk Management
 Determine Your Team’s Type of Software Risks
 Technical
 Management related
 Financial related
 Contractual /Legal related
 Personnel related
 Other Areas such as inadequate tool, unavailability of system resources
Identifying Risks
Risk Factors To Prioritize Risks
Context – Events, Conditions, Constraints, and
assumptions
Estimated Risk Probability – Likelihood the risk will turn
into a problem
Analyzing Risks
ASQ Section 509 SIG
Practical Risk Management
The primary purpose of risk analysis is to determine your
highest priority risks; and to figure out what actions need to be
taken to reduce those risks.
Assess Risk Factors To Prioritize Risks
Time Frames – This is the time frame in which the risk must
be addressed
Exposure – Impact of a risk in terms of its expected value
Analyzing Risks
ASQ Section 509 SIG
Practical Risk Management
Assess Risk Factors To Prioritize Risks
Tolerance - The willingness to accept or avoid risk. People and
organizations have differing risk tolerances. Some project
stakeholders want to risk the delivery of the project they are
paying for by taking a chance on something new. Other will
welcome the opportunity if the danger is not too great
Analyzing Risks
ASQ Section 509 SIG
Practical Risk Management
Stakeholders (Low Tolerance
Level)
Customers (Low Tolerance
Level)
Team Members (Low to Medium
Tolerance Level)
- Understands how the
technology will be
integrated
- Must comply with
multiple levels for
governmental
regulations
- Very low tolerance for
any type of system
failure
- Requires the highest
level of quality
- Understands how the
technology will be
integrated into their
business process
- Very much involved in
the day to day testing
effort
- Works well with the
project team to
overcome any road
blocks and get
answers to questions
related to business
process
- Very close to the technology;
In depth knowledge of business
requirements;
- Work effectively with other test
teams in the field and
communicate effectively with
development staff
Consider the Risk Tolerance of Your Stakeholders, Customers,
and Team Members
ASQ Section 509 SIG
Practical Risk Management
ASQ Section 509 SIG
Practical Risk Management
Analyzing Risks
RISK EXPOSURE
RE = Probability (Unexpected outcome) X LOSS (Unexpected Outcome)
Source: Software Quality Engineer Handbook; Linda Westfall
Risk Actions
Four typical actions that we can take:
Mitigate: Take steps in advance to reduce the possibility and impact of the
risk.
Contingency: Have a plan in place to reduce the possibility of the risk to
become an outcome.
Transfer: Convince some other member of the team or project stakeholder to
reduce the probability or accept the impact of the risk.
Ignore: Ignore the risk, which is usually a good option only when there is little
that can be done or when the possibility and impact of that risk are low in the
project.
Taking Action
ASQ Section 509 SIG
Practical Risk Management
ASQ Section 509 SIG
Practical Risk Management
The Goal: Proactively Manage Risks on a Daily Basis
 Take Action to Control the Impact of Risks
 Prioritize and re-prioritize work based on risk level
 Discuss risks with team members; and add a discussion on
risk as a part of daily status meetings
A Case Study
Project Status: Pre -Production
Field testing is in progress and covers several sites; sites are tested each day
to collect data for analysis by senior management
Test team conducts a brief system check to ensure all system components are
operational.
• System Monitor
• Receipt Printer
• Card reader ‘A’
ASQ Section 509 SIG
Practical Risk Management
General / Non-Technical Risk Areas To Consider
Overall System Complexity
 this site test is a major part of a much larger system; the team needs to know who to
contact if there are issues that need to be resolved in the field
Site Test environment
 there are many customer constraints for space and equipment and staff within the site
office where testing done
Site Test Staff Training
 Since engineering interns make up a great portion of the staff, training for new testers is
ongoing.
 Interspersed Development and QA teams
 When an issue is reported from the field, it can be a challenge to communicate details to
a remotely located development team
ASQ Section 509 SIG
Practical Risk Management
Technical Risks
Events have been identified that may pose a risk to the project and stakeholders
 A button on the touch screen does not respond when selected on the first try; when selected
again, the button behaves as expected
ASQ Section 509 SIG
Practical Risk Management
Receipt
Printer
System A
Reports
Pin Pad
Card
Reader
ASQ Section 509 SIG
Practical Risk Management
 Team executes test scripts to ensure system functionality
 Executes cash and credit transactions at the system monitor to ensure all products
can be successfully purchased
 Cash drawer is counted
 Reports are run
 Deposit slips are generated.
 Products created during the site test are validated.
 Test data is captured by independent validation team and uploaded to secure site
for analysis
ASQ Section 509 SIG
Practical Risk Management
ASQ Section 509 SIG
Practical Risk Management
 Do we have enough information about the risk?
 Is the risk greater than we can accept?
 Can the risk be transferred to another party?
 Is action needed now? Is action needed if the problem
occurs?
 Can we accept the risk?
Planning Phase Questions to Consider
Event Potential Problem
for the Customer
Contributing
Factors
Constraints
/Assumptions
Circumstances
/contributing
factors
Related issues that can lead to
a problem
System
Monitor
Touch
Screen
Recoverable touch
screen button
issues;
Button does not
activate when
selected on first try
The button
functions after
several tries;
an annoyance
to the customer
Button issues
is not related
to system
software
Touch Screen
sensitivity needs to
be evaluated
Since the problem is related to
the screen and not the software,
operators need a process to
evaluate and adjust screen
sensitivity
ASQ Section 509 SIG
Practical Risk Management
Impact on
project
Risk The Challenge (Why?) Opportunity for
Improvement
Taking Action to
Remediate the Problem
High Unplanned
Breaks in
Test
Schedule
Site test scheduling conflicts
and lockouts
This an opportunity to
preschedule work
with our customer to
avoid conflict.
Follow-up with Senior
Management on a site
test schedule pre-
approved by client for
the upcoming week of
testing.
Brainstorming Risks as They Impact
the Project
ASQ Section 509 SIG
Practical Risk Management
ASQ Section 509 SIG
Practical Risk Management
Communicating Risk In Terms of Risk Exposure
Risk Risk Tolerance Context Likelihood
of
occurrence
Loss
(Days
)
Risk
Exposure
Action
Without the
appropriate
business process
established (within
the preproduction
time frame), the
client’s financial
reporting cannot
be delivered on
time
Client is willing
to accept the
financial
reporting after
the scheduled
delivery date
Development
Team is
dependent on
completion of
business
process
changes to
revise client’s
financial
reporting.
.90 7 6.3 Transfer risk to the client
by specifying late delivery
if appropriate processes
are not available (within
the pre-production
timeframe)
Button on touch
Screen does not
function for
several keys
Client is
knowledgeable
of the possible
risk.
Hardware and
software
issues have
been ruled
out.
.02 .5 .01 Transfer the risk to the
maintenance team provide
client with a procedure to
adjust screen sensitivity

Más contenido relacionado

La actualidad más candente

Software Project Management: Risk Management
Software Project Management: Risk ManagementSoftware Project Management: Risk Management
Software Project Management: Risk ManagementMinhas Kamal
 
Unit 8-risk manaegement (1) -
Unit 8-risk manaegement (1) - Unit 8-risk manaegement (1) -
Unit 8-risk manaegement (1) - Shashi Kumar
 
Bertrand's Individual Essay
Bertrand's Individual EssayBertrand's Individual Essay
Bertrand's Individual EssayPrince Bertrand
 
Assessment Of Risk Mitigation
Assessment Of Risk MitigationAssessment Of Risk Mitigation
Assessment Of Risk MitigationEneni Oduwole
 
Cse it seminar ppt1, An Approach To IT Project Management
Cse it seminar ppt1, An Approach To IT Project ManagementCse it seminar ppt1, An Approach To IT Project Management
Cse it seminar ppt1, An Approach To IT Project ManagementGirija Sankar Dash
 
Software testing - Risk management
Software testing - Risk managementSoftware testing - Risk management
Software testing - Risk managementPractiTest
 
Iwsm2014 defining technical risk in software development (vard antinyan)
Iwsm2014   defining technical risk in software development (vard antinyan)Iwsm2014   defining technical risk in software development (vard antinyan)
Iwsm2014 defining technical risk in software development (vard antinyan)Nesma
 
Project Risk Management - Introduction 2011
Project Risk Management - Introduction 2011Project Risk Management - Introduction 2011
Project Risk Management - Introduction 2011Sasha Lazarevic
 
Risk Analysis Workbook
Risk Analysis WorkbookRisk Analysis Workbook
Risk Analysis Workbookdmdk12
 
Risk analysis and management
Risk analysis and managementRisk analysis and management
Risk analysis and managementgnitu
 
Software Engineering Risk Management Software Application
Software Engineering Risk Management   Software ApplicationSoftware Engineering Risk Management   Software Application
Software Engineering Risk Management Software Applicationguestfea9c55
 
Risk Management Software Implementation Guide eBook
Risk Management Software Implementation Guide eBookRisk Management Software Implementation Guide eBook
Risk Management Software Implementation Guide eBookGlenn Peake
 
Risk Mitigation, Monitoring and Management Plan (RMMM)
Risk Mitigation, Monitoring and Management Plan (RMMM)Risk Mitigation, Monitoring and Management Plan (RMMM)
Risk Mitigation, Monitoring and Management Plan (RMMM)Navjyotsinh Jadeja
 
12.0 risk management agile+evm (v10.2)
12.0 risk management agile+evm (v10.2)12.0 risk management agile+evm (v10.2)
12.0 risk management agile+evm (v10.2)Glen Alleman
 

La actualidad más candente (20)

Software Project Management: Risk Management
Software Project Management: Risk ManagementSoftware Project Management: Risk Management
Software Project Management: Risk Management
 
Risk Management by Roger Pressman
Risk Management by Roger PressmanRisk Management by Roger Pressman
Risk Management by Roger Pressman
 
Unit 8-risk manaegement (1) -
Unit 8-risk manaegement (1) - Unit 8-risk manaegement (1) -
Unit 8-risk manaegement (1) -
 
Bertrand's Individual Essay
Bertrand's Individual EssayBertrand's Individual Essay
Bertrand's Individual Essay
 
Assessment Of Risk Mitigation
Assessment Of Risk MitigationAssessment Of Risk Mitigation
Assessment Of Risk Mitigation
 
Cse it seminar ppt1, An Approach To IT Project Management
Cse it seminar ppt1, An Approach To IT Project ManagementCse it seminar ppt1, An Approach To IT Project Management
Cse it seminar ppt1, An Approach To IT Project Management
 
Software testing - Risk management
Software testing - Risk managementSoftware testing - Risk management
Software testing - Risk management
 
Iwsm2014 defining technical risk in software development (vard antinyan)
Iwsm2014   defining technical risk in software development (vard antinyan)Iwsm2014   defining technical risk in software development (vard antinyan)
Iwsm2014 defining technical risk in software development (vard antinyan)
 
Risk Management
Risk ManagementRisk Management
Risk Management
 
Risk management case study
Risk management case studyRisk management case study
Risk management case study
 
Project Risk Management - Introduction 2011
Project Risk Management - Introduction 2011Project Risk Management - Introduction 2011
Project Risk Management - Introduction 2011
 
Risk management
Risk managementRisk management
Risk management
 
Risk Analysis Workbook
Risk Analysis WorkbookRisk Analysis Workbook
Risk Analysis Workbook
 
Risk analysis and management
Risk analysis and managementRisk analysis and management
Risk analysis and management
 
Derek Wright: risk v uncertainty case study
Derek Wright: risk v uncertainty case studyDerek Wright: risk v uncertainty case study
Derek Wright: risk v uncertainty case study
 
Software Engineering Risk Management Software Application
Software Engineering Risk Management   Software ApplicationSoftware Engineering Risk Management   Software Application
Software Engineering Risk Management Software Application
 
Risk Management Software Implementation Guide eBook
Risk Management Software Implementation Guide eBookRisk Management Software Implementation Guide eBook
Risk Management Software Implementation Guide eBook
 
Software Engineering
Software EngineeringSoftware Engineering
Software Engineering
 
Risk Mitigation, Monitoring and Management Plan (RMMM)
Risk Mitigation, Monitoring and Management Plan (RMMM)Risk Mitigation, Monitoring and Management Plan (RMMM)
Risk Mitigation, Monitoring and Management Plan (RMMM)
 
12.0 risk management agile+evm (v10.2)
12.0 risk management agile+evm (v10.2)12.0 risk management agile+evm (v10.2)
12.0 risk management agile+evm (v10.2)
 

Destacado (10)

SWOT-Analysis
SWOT-AnalysisSWOT-Analysis
SWOT-Analysis
 
ResumeBekki
ResumeBekkiResumeBekki
ResumeBekki
 
Лечение ОРЗ народными средствами
 Лечение  ОРЗ народными средствами Лечение  ОРЗ народными средствами
Лечение ОРЗ народными средствами
 
Realtor awards opening speech 1
Realtor awards opening speech 1Realtor awards opening speech 1
Realtor awards opening speech 1
 
Cap 01-pdf1
Cap 01-pdf1Cap 01-pdf1
Cap 01-pdf1
 
Resume bekki
Resume bekkiResume bekki
Resume bekki
 
Anjitha
AnjithaAnjitha
Anjitha
 
Dissertation - BA (Hons) Media
Dissertation - BA (Hons) MediaDissertation - BA (Hons) Media
Dissertation - BA (Hons) Media
 
The EISA Audit Presentation
The EISA Audit  PresentationThe EISA Audit  Presentation
The EISA Audit Presentation
 
CV-022516-Linkedin
CV-022516-LinkedinCV-022516-Linkedin
CV-022516-Linkedin
 

Similar a R1

Webinar - Building Team Efficiency and Effectiveness
Webinar - Building Team Efficiency and EffectivenessWebinar - Building Team Efficiency and Effectiveness
Webinar - Building Team Efficiency and EffectivenessInvensis Learning
 
Rethinking Risk-Based Project Management in the Emerging IT initiatives.pptx
Rethinking Risk-Based Project Management in the Emerging IT initiatives.pptxRethinking Risk-Based Project Management in the Emerging IT initiatives.pptx
Rethinking Risk-Based Project Management in the Emerging IT initiatives.pptxInflectra
 
Getting Executive Support for a Software Security Program
Getting Executive Support for a Software Security ProgramGetting Executive Support for a Software Security Program
Getting Executive Support for a Software Security ProgramCigital
 
Process Maturity Assessment
Process Maturity AssessmentProcess Maturity Assessment
Process Maturity Assessmentpchronis
 
SPM RISK PLANNING.pdfddddddddddddddddddddddddddddddddddddddddddddddd
SPM RISK PLANNING.pdfdddddddddddddddddddddddddddddddddddddddddddddddSPM RISK PLANNING.pdfddddddddddddddddddddddddddddddddddddddddddddddd
SPM RISK PLANNING.pdfdddddddddddddddddddddddddddddddddddddddddddddddShepherdChidambaeh
 
Designing NextGen Threat Identification Solutions
Designing NextGen Threat Identification SolutionsDesigning NextGen Threat Identification Solutions
Designing NextGen Threat Identification SolutionsArun Prabhakar
 
Software Engineering
Software EngineeringSoftware Engineering
Software EngineeringVijayapriyaP1
 
AFITC 2018 - Using Process Maturity and Agile to Strengthen Cyber Security
AFITC 2018 - Using Process Maturity and Agile to Strengthen Cyber SecurityAFITC 2018 - Using Process Maturity and Agile to Strengthen Cyber Security
AFITC 2018 - Using Process Maturity and Agile to Strengthen Cyber SecurityDjindo Lee
 
Enterprise 360 degree risk management
Enterprise 360 degree risk managementEnterprise 360 degree risk management
Enterprise 360 degree risk managementInfosys
 
Software Engineering :Project Management
Software Engineering :Project ManagementSoftware Engineering :Project Management
Software Engineering :Project Managementsimmis5
 
project_risk_mgmt_final 1.ppt
project_risk_mgmt_final 1.pptproject_risk_mgmt_final 1.ppt
project_risk_mgmt_final 1.pptBetshaTizazu2
 
On Risks and Agile Approaches
On Risks and Agile ApproachesOn Risks and Agile Approaches
On Risks and Agile ApproachesEmiliano Soldi
 
PMI project_risk_management_final_2022.ppt
PMI project_risk_management_final_2022.pptPMI project_risk_management_final_2022.ppt
PMI project_risk_management_final_2022.pptDorraLamouchi1
 
project_risk_mgmt_final.ppt
project_risk_mgmt_final.pptproject_risk_mgmt_final.ppt
project_risk_mgmt_final.pptavisha23
 
project_risk_mgmt_final.ppt
project_risk_mgmt_final.pptproject_risk_mgmt_final.ppt
project_risk_mgmt_final.pptAyidAlmgati
 
Application Security - Dont leave your AppSec for the last moment Meetup 2104...
Application Security - Dont leave your AppSec for the last moment Meetup 2104...Application Security - Dont leave your AppSec for the last moment Meetup 2104...
Application Security - Dont leave your AppSec for the last moment Meetup 2104...lior mazor
 
iDEAFest Enteprise InfoSec Program Lessons Learned
iDEAFest Enteprise InfoSec Program Lessons LearnediDEAFest Enteprise InfoSec Program Lessons Learned
iDEAFest Enteprise InfoSec Program Lessons LearnedMichael King
 
Microsoft InfoSec for cloud and mobile
Microsoft InfoSec for cloud and mobileMicrosoft InfoSec for cloud and mobile
Microsoft InfoSec for cloud and mobileVijayananda Mohire
 

Similar a R1 (20)

Webinar - Building Team Efficiency and Effectiveness
Webinar - Building Team Efficiency and EffectivenessWebinar - Building Team Efficiency and Effectiveness
Webinar - Building Team Efficiency and Effectiveness
 
Rethinking Risk-Based Project Management in the Emerging IT initiatives.pptx
Rethinking Risk-Based Project Management in the Emerging IT initiatives.pptxRethinking Risk-Based Project Management in the Emerging IT initiatives.pptx
Rethinking Risk-Based Project Management in the Emerging IT initiatives.pptx
 
Getting Executive Support for a Software Security Program
Getting Executive Support for a Software Security ProgramGetting Executive Support for a Software Security Program
Getting Executive Support for a Software Security Program
 
Process Maturity Assessment
Process Maturity AssessmentProcess Maturity Assessment
Process Maturity Assessment
 
Risk Management
Risk ManagementRisk Management
Risk Management
 
SPM RISK PLANNING.pdfddddddddddddddddddddddddddddddddddddddddddddddd
SPM RISK PLANNING.pdfdddddddddddddddddddddddddddddddddddddddddddddddSPM RISK PLANNING.pdfddddddddddddddddddddddddddddddddddddddddddddddd
SPM RISK PLANNING.pdfddddddddddddddddddddddddddddddddddddddddddddddd
 
Project Risk Management
Project Risk ManagementProject Risk Management
Project Risk Management
 
Designing NextGen Threat Identification Solutions
Designing NextGen Threat Identification SolutionsDesigning NextGen Threat Identification Solutions
Designing NextGen Threat Identification Solutions
 
Software Engineering
Software EngineeringSoftware Engineering
Software Engineering
 
AFITC 2018 - Using Process Maturity and Agile to Strengthen Cyber Security
AFITC 2018 - Using Process Maturity and Agile to Strengthen Cyber SecurityAFITC 2018 - Using Process Maturity and Agile to Strengthen Cyber Security
AFITC 2018 - Using Process Maturity and Agile to Strengthen Cyber Security
 
Enterprise 360 degree risk management
Enterprise 360 degree risk managementEnterprise 360 degree risk management
Enterprise 360 degree risk management
 
Software Engineering :Project Management
Software Engineering :Project ManagementSoftware Engineering :Project Management
Software Engineering :Project Management
 
project_risk_mgmt_final 1.ppt
project_risk_mgmt_final 1.pptproject_risk_mgmt_final 1.ppt
project_risk_mgmt_final 1.ppt
 
On Risks and Agile Approaches
On Risks and Agile ApproachesOn Risks and Agile Approaches
On Risks and Agile Approaches
 
PMI project_risk_management_final_2022.ppt
PMI project_risk_management_final_2022.pptPMI project_risk_management_final_2022.ppt
PMI project_risk_management_final_2022.ppt
 
project_risk_mgmt_final.ppt
project_risk_mgmt_final.pptproject_risk_mgmt_final.ppt
project_risk_mgmt_final.ppt
 
project_risk_mgmt_final.ppt
project_risk_mgmt_final.pptproject_risk_mgmt_final.ppt
project_risk_mgmt_final.ppt
 
Application Security - Dont leave your AppSec for the last moment Meetup 2104...
Application Security - Dont leave your AppSec for the last moment Meetup 2104...Application Security - Dont leave your AppSec for the last moment Meetup 2104...
Application Security - Dont leave your AppSec for the last moment Meetup 2104...
 
iDEAFest Enteprise InfoSec Program Lessons Learned
iDEAFest Enteprise InfoSec Program Lessons LearnediDEAFest Enteprise InfoSec Program Lessons Learned
iDEAFest Enteprise InfoSec Program Lessons Learned
 
Microsoft InfoSec for cloud and mobile
Microsoft InfoSec for cloud and mobileMicrosoft InfoSec for cloud and mobile
Microsoft InfoSec for cloud and mobile
 

R1

  • 1. ASQ Section 509 SIG Practical Risk Management WELCOME!  Objectives:  Review basic definitions  Take a quick look at some related standards and CMMI  Process Steps: Integrating a risk management approach into the project life cycle  Walk through a sample project to demonstrate risk management techniques
  • 2. ASQ Section 509 SIG Practical Risk Management What is Risk Management? ‘Risks’ have not happened yet… ‘Risk’ is the probability of an event occurring with the possibility of derailing project success. ‘Risks’ that are not managed and controlled can have a negative impact on a project team’s Deliverables Budget Product Quality
  • 3. ASQ Section 509 SIG Practical Risk Management Definitions of Risk IEEE: The likelihood of an event, hazard, threat, or situation occurring some time in the future Definition (ISTQB) - Systematic application of procedures and practices to the tasks of identifying, analyzing, prioritizing, and controlling risks How Do You Define Risks?
  • 4. ASQ Section 509 SIG Practical Risk Management ISO Standards Related to Managing Risks ISO/ IEC 27002:2013 - Details security policy requirements for protecting an organization's physical and information technology assets ISO 31000:2009, Risk management – details a framework and process for managing risk. ISO Guide 73:2009, Risk management - details terms and definitions relating to the management of risk. ISO/IEC 31010:2009, Risk management – Risk assessment techniques focuses on risk assessment
  • 5. ASQ Section 509 SIG Practical Risk Management CMMI and Risk Management Risk management is a project management process area for maturity level 3 organizations. The purpose of risk management (RSKM) is to identify potential issues or problems before they occur; and to have planned activities in place and available to reduce or eliminate the impact of the risk. For level three organizations, risk management should be an ongoing integrated process; and will address issues that could possibly have a negative impact on project deliverables, costs, and objectives. Source: Software-Quality-Assurance.org is an independent Web Site that presents information about CMMi
  • 6. ASQ Section 509 SIG Practical Risk Management Consider Levels of Risk Maturity (1) Not aware of the need for risk management (2) Organizations are aware of the potential benefits, however have not implemented process (3) Built management of risks into routine business processes (4) Have a risk aware culture Source: Fundamentals of Risk Management by Paul Hopkin
  • 7. ASQ Section 509 SIG Practical Risk Management Traditional /Waterfall Approach Agile Approach  Project management focuses on costs and schedule, and project goals at a high level.  Tends not to be a working document for teams to use.  Focus is on ‘day to day’ issues and is managed through standups, focus groups, and lessons learned, however there is no formal risk management process shared with the team. When comparing Agile Scrum to Traditional / Waterfall projects, there is no defined process for risk management
  • 8. ASQ Section 509 SIG Practical Risk Management How do you define risks?
  • 9. ASQ Section 509 SIG Practical Risk Management What’s your experience with regard to risk management? Is risk management relevant to your daily project work?
  • 10. Track AnalyzeIdentify Plan ASQ Section 509 SIG Practical Risk Management
  • 11. Discuss the project risks openly Taxonomy Based Questionnaire – www.sei.cmu.edu/reports/93tr006. pdf Conduct interviews, reports Focus on risks unique to project Use decomposition to identify risks within the work breakdown structure Focus is on undesirable consequence (events, hazards, threats) ASQ Section 509 SIG Practical Risk Management Identifying Risks
  • 12. SEI’s Software Development Risk Taxonomy questionnaire can help facilitate risk identification in a specific area of software development. ASQ Section 509 SIG Practical Risk Management Identifying Risks
  • 13. ASQ Section 509 SIG Practical Risk Management Identifying Risks Input Output Brain storm problems and issues that can impact the team’s ability to deliver quality products to the customer Generate an easy to update risk list for tracking actions
  • 14. ASQ Section 509 SIG Practical Risk Management  Determine Your Team’s Type of Software Risks  Technical  Management related  Financial related  Contractual /Legal related  Personnel related  Other Areas such as inadequate tool, unavailability of system resources Identifying Risks
  • 15. Risk Factors To Prioritize Risks Context – Events, Conditions, Constraints, and assumptions Estimated Risk Probability – Likelihood the risk will turn into a problem Analyzing Risks ASQ Section 509 SIG Practical Risk Management The primary purpose of risk analysis is to determine your highest priority risks; and to figure out what actions need to be taken to reduce those risks.
  • 16. Assess Risk Factors To Prioritize Risks Time Frames – This is the time frame in which the risk must be addressed Exposure – Impact of a risk in terms of its expected value Analyzing Risks ASQ Section 509 SIG Practical Risk Management
  • 17. Assess Risk Factors To Prioritize Risks Tolerance - The willingness to accept or avoid risk. People and organizations have differing risk tolerances. Some project stakeholders want to risk the delivery of the project they are paying for by taking a chance on something new. Other will welcome the opportunity if the danger is not too great Analyzing Risks ASQ Section 509 SIG Practical Risk Management
  • 18. Stakeholders (Low Tolerance Level) Customers (Low Tolerance Level) Team Members (Low to Medium Tolerance Level) - Understands how the technology will be integrated - Must comply with multiple levels for governmental regulations - Very low tolerance for any type of system failure - Requires the highest level of quality - Understands how the technology will be integrated into their business process - Very much involved in the day to day testing effort - Works well with the project team to overcome any road blocks and get answers to questions related to business process - Very close to the technology; In depth knowledge of business requirements; - Work effectively with other test teams in the field and communicate effectively with development staff Consider the Risk Tolerance of Your Stakeholders, Customers, and Team Members ASQ Section 509 SIG Practical Risk Management
  • 19. ASQ Section 509 SIG Practical Risk Management Analyzing Risks RISK EXPOSURE RE = Probability (Unexpected outcome) X LOSS (Unexpected Outcome) Source: Software Quality Engineer Handbook; Linda Westfall
  • 20. Risk Actions Four typical actions that we can take: Mitigate: Take steps in advance to reduce the possibility and impact of the risk. Contingency: Have a plan in place to reduce the possibility of the risk to become an outcome. Transfer: Convince some other member of the team or project stakeholder to reduce the probability or accept the impact of the risk. Ignore: Ignore the risk, which is usually a good option only when there is little that can be done or when the possibility and impact of that risk are low in the project. Taking Action ASQ Section 509 SIG Practical Risk Management
  • 21. ASQ Section 509 SIG Practical Risk Management The Goal: Proactively Manage Risks on a Daily Basis  Take Action to Control the Impact of Risks  Prioritize and re-prioritize work based on risk level  Discuss risks with team members; and add a discussion on risk as a part of daily status meetings
  • 22. A Case Study Project Status: Pre -Production Field testing is in progress and covers several sites; sites are tested each day to collect data for analysis by senior management Test team conducts a brief system check to ensure all system components are operational. • System Monitor • Receipt Printer • Card reader ‘A’ ASQ Section 509 SIG Practical Risk Management
  • 23. General / Non-Technical Risk Areas To Consider Overall System Complexity  this site test is a major part of a much larger system; the team needs to know who to contact if there are issues that need to be resolved in the field Site Test environment  there are many customer constraints for space and equipment and staff within the site office where testing done Site Test Staff Training  Since engineering interns make up a great portion of the staff, training for new testers is ongoing.  Interspersed Development and QA teams  When an issue is reported from the field, it can be a challenge to communicate details to a remotely located development team ASQ Section 509 SIG Practical Risk Management
  • 24. Technical Risks Events have been identified that may pose a risk to the project and stakeholders  A button on the touch screen does not respond when selected on the first try; when selected again, the button behaves as expected ASQ Section 509 SIG Practical Risk Management
  • 25. Receipt Printer System A Reports Pin Pad Card Reader ASQ Section 509 SIG Practical Risk Management
  • 26.  Team executes test scripts to ensure system functionality  Executes cash and credit transactions at the system monitor to ensure all products can be successfully purchased  Cash drawer is counted  Reports are run  Deposit slips are generated.  Products created during the site test are validated.  Test data is captured by independent validation team and uploaded to secure site for analysis ASQ Section 509 SIG Practical Risk Management
  • 27. ASQ Section 509 SIG Practical Risk Management  Do we have enough information about the risk?  Is the risk greater than we can accept?  Can the risk be transferred to another party?  Is action needed now? Is action needed if the problem occurs?  Can we accept the risk? Planning Phase Questions to Consider
  • 28. Event Potential Problem for the Customer Contributing Factors Constraints /Assumptions Circumstances /contributing factors Related issues that can lead to a problem System Monitor Touch Screen Recoverable touch screen button issues; Button does not activate when selected on first try The button functions after several tries; an annoyance to the customer Button issues is not related to system software Touch Screen sensitivity needs to be evaluated Since the problem is related to the screen and not the software, operators need a process to evaluate and adjust screen sensitivity ASQ Section 509 SIG Practical Risk Management
  • 29. Impact on project Risk The Challenge (Why?) Opportunity for Improvement Taking Action to Remediate the Problem High Unplanned Breaks in Test Schedule Site test scheduling conflicts and lockouts This an opportunity to preschedule work with our customer to avoid conflict. Follow-up with Senior Management on a site test schedule pre- approved by client for the upcoming week of testing. Brainstorming Risks as They Impact the Project ASQ Section 509 SIG Practical Risk Management
  • 30. ASQ Section 509 SIG Practical Risk Management Communicating Risk In Terms of Risk Exposure Risk Risk Tolerance Context Likelihood of occurrence Loss (Days ) Risk Exposure Action Without the appropriate business process established (within the preproduction time frame), the client’s financial reporting cannot be delivered on time Client is willing to accept the financial reporting after the scheduled delivery date Development Team is dependent on completion of business process changes to revise client’s financial reporting. .90 7 6.3 Transfer risk to the client by specifying late delivery if appropriate processes are not available (within the pre-production timeframe) Button on touch Screen does not function for several keys Client is knowledgeable of the possible risk. Hardware and software issues have been ruled out. .02 .5 .01 Transfer the risk to the maintenance team provide client with a procedure to adjust screen sensitivity

Notas del editor

  1. Risk management involves 4 basic process steps. Identify, Analyze, Plan, and Track . The first step is identifying risks and consolidating them in a list for analysis.
  2. The primary purpose of risk analysis is to determine your highest priority risks; and to figure out what actions need to be taken to reduce those risks. The context is the data that been gathered on the risk such as a description of the event, conditions, constraints, assumptions, contributing factors, and impact on other project deliverables
  3. The primary purpose of risk analysis is to determine your highest priority risks; and to figure out what actions need to be taken to reduce those risks. The context is the data that been gathered on the risk such as a description of the event, conditions, constraints, assumptions, contributing factors, and impact on other project deliverables
  4. The primary purpose of risk analysis is to determine your highest priority risks; and to figure out what actions need to be taken to reduce those risks. The context is the data that been gathered on the risk such as a description of the event, conditions, constraints, assumptions, contributing factors, and impact on other project deliverables
  5. Boehm (1989) defines Risk Exposure to help quantitatively establish risk Priorities.
  6. The primary purpose of risk analysis is to determine your highest priority risks; and to figure out what actions need to be taken to reduce those risks. The context is the data that been gathered on the risk such as a description of the event, conditions, constraints, assumptions, contributing factors, and impact on other project deliverables