Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Risk management


Published on

Published in: Education, Technology, Business
  • Be the first to comment

Risk management

  2. 2. CONTENTS • • • • • • What is a risk? What is risk management? Principles for managing risk? Types of software risk? Risk Analysis How to control risk in project 2
  3. 3. What is RISK • • • • Risk is the probability of suffering loss (an uncertainty) Risk exposure = Size (loss) * probability of (loss) There is difference between problem and risk Problem is some event which has already occurred but risk is something that is unpredictable. • Risk provides opportunity to develop the project better • Example: developer leaving out from a team which is ongoing with a project 3
  4. 4. RISK MANAGEMENT • Risk we encounter in a project be reduced so that we are able to deliver the desired project to customer. • The project should be managed in such a way that the risk don’t effect the project in a big way. • The art of managing the risk effectively so that the winning situation and friendly situation is established between team and the customer is called Risk management • By using various principles we can manage risk 4
  5. 5. PRINCIPLES OF RISK MANAGEMENT • Global Perspective: In this we look at the larger system definitions, design and implementation. We look at the opportunity and the impact the risk is going to have . • Forward Looking View: Looking at the possible uncertainties that might creep up. We also think for the possible solutions for those risks that might occur in the future. • Open Communication: This is to enable the free flow of communication between in the customers and the team members so that they have clarity about the risks. 5
  6. 6. PRINCIPLES OF RISK MANAGEMENT contd. • Integrated management: In this phase risk management is made an integral part of project management. • Continuous process :In this phase the risks are tracked continuously throughout the risk management paradigm. 6
  7. 7. SOFTWARE RISK • Project Risks: Threaten the project plan • Technical Risks: Threaten product quality and the timeliness of the schedule • Business Risks: Threaten the viability of the software to be built (market risks, strategic risks, management risks, budget risks) • Known Risks: Predictable from careful evaluation of current project plan and those extrapolated from past project experience • Unknown Risks: Some problems will simply occur without warning 7
  8. 8. RISK ANALYSIS • Risk identification • Risk projection-(impact of risks) • Risk assessment-(what will change if risk becomes problem) • Risk management 8
  9. 9. RISK IDENTIFICATION • Product-specific risks – The project plan and software statement of scope are examined to identify any special characteristics of the product that may threaten the project plan • Generic risks – are potential threats to every software product • • • • product size customer characteristics development environment technology to be built 9
  10. 10. RISK PROJECTION • The risk drivers affecting each risk component are – classified according to their impact category – potential consequences of each undetected software fault or unachieved project outcome are described 10
  11. 11. RISK IMPACT • Risk components – – – – performance cost support schedule • Risk impact – – – – negligible marginal critical catastrophic 11
  12. 12. RISK ASSESSMENT • Define referent levels for each project risk that can cause project termination – – – – performance degradation cost overrun support difficulty schedule slippage • Attempt to develop a relationship between each risk triple (risk, probability, impact) and each of the reference levels 12
  13. 13. RISK TABLE CONSTRUCTION • List all risks in the first column of the table • Classify each risk and enter the category label in second column • Determine a probability for each risk and enter it into column three • Enter the severity of each risk (negligible, marginal, critical, catastrophic) in column four. 13
  14. 14. RISK TABLE CONSTRUCTION (contd.) • Sort the table by probability and impact value • Determine the criteria for deciding where the sorted table will be divided into the first priority concerns and the second priority concerns • First priority concerns must be managed (a fifth column can be added to contain a pointer into the RMMM document) 14
  15. 15. RISK TABLE MODEL Risks Category Probability Impact RMMM PS 80% 2 ** ST 50% 2 ** DE 50% 2 ** DE 35% 3 Components developed separately cannot be integrated easily, requiring redesign Development of the wrong software functions requires redesign and implementation Development of extra software functions that are not needed Strict requirements for compatibility with existing system require more testing, design, and implementation than expected Operation in unfamiliar software environment causes unforeseen problems Team members do not work well together DE 25% 3 DE 25% 3 DE 20% 3 DE 20% 3 EV 25% 4 ST 20% 4 Key personnel are available only part-time ST 20% 4 Estimated size of project in LOC or FP Lack of needed specialization increases defects and reworks Unfamiliar areas of the product take more time than expected to design and implement Does the environment make use of a database 15
  16. 16. RISK TABLE MODEL 16
  17. 17. RMMM • Risk Mitigation- Planning • Risk Monitoring- Assessing, Ensuring, Collecting information, Determining • Risk Management- Contingency planning, Action 17
  18. 18. RISK MANAGEMENT PARADIGM • Identify: Search for the risks before they create a major problem. • Analyze: understand the nature , kind of risk and gather information about the risk. • Plan: Involves developing actions to address individual risks, prioritizing • risk actions and creating a Risk Management Plan. • Track: Monitoring the status of risk. • Control: Correct the deviation and make any necessary amendments. • Communicate: Discuss about the emerging risks and the current risks and the plans to be undertaken. 18
  20. 20. CONCLUSION • To manage the risks we need to establish a strong bond between the customers and the team members. • A strong base about risk management would help a great deal in tackling the risks. • Software metrics and tools can be developed to manage the risks. • Risk necessarily need not be negative and it can be viewed as an opportunity to develop our projects in a better way. 20
  21. 21. QUERIES 21
  22. 22. THANK YOU 22