Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Risk management in Software Projects José Onofre Montesa Andrés Universidad Politécnica de Valencia Escuela Superior de Informática Aplicada 2003-2004
  2. 2. Índice <ul><li>Failure and root causes. </li></ul><ul><li>Risk Definition </li></ul><ul><li>Formas en las que se afrontan las causas de las desviaciones </li></ul><ul><li>Elementos de la Gestión de Riesgos </li></ul><ul><ul><li>Identificar los factores de Riesgo </li></ul></ul><ul><ul><li>Evaluar la probabilidad y el efecto </li></ul></ul><ul><ul><li>Desarrollo de estrategias para mitigar los riesgos </li></ul></ul><ul><li>Monitorizar los factores de riesgo </li></ul>
  3. 3. Failure and root causes. <ul><li>Software projects fail if: </li></ul><ul><ul><li>Software never runs. </li></ul></ul><ul><ul><li>Don’t accomplish same expected functions. </li></ul></ul><ul><ul><li>Software isn't delivered on time. </li></ul></ul><ul><ul><li>Higher cost than expected. </li></ul></ul><ul><li>Reasons: </li></ul><ul><ul><li>High level of complexity (communications, interrelation with other systems, etc..) </li></ul></ul><ul><ul><li>Uncertainty. It wasn’t clear the objective. </li></ul></ul>
  4. 4. Risk Definition (Fairley) <ul><li>Risk is a potential problem. </li></ul><ul><li>Problem is a risk that has materialized. </li></ul><ul><li>By a problem, we mean an undesirable situation that will require time and resources to correct. </li></ul><ul><ul><li>(may be uncorrectable). </li></ul></ul><ul><li>A risk is characterized by: </li></ul><ul><ul><li>The probability that occur (0<P<1) </li></ul></ul><ul><ul><li>A loss associated </li></ul></ul>
  5. 5. Risk factors fall into two categories <ul><ul><li>Generic risks, common to all software projects, then we tray to improve the organization to overcome this risks or we have a check list. </li></ul></ul><ul><ul><li>Project specific risks. </li></ul></ul><ul><li>This are complementary points of view we must act on both. </li></ul>
  6. 6. Most Common Software Risks (1) (Caper Jones) <ul><li>Ambiguous improvement targets.(4) </li></ul><ul><li>Creeping users requirements.(9) </li></ul><ul><li>Crowded office conditions.(10) </li></ul><ul><li>Excessive schedule pressure.(13) </li></ul><ul><li>Excessive time to market.(14) </li></ul><ul><li>Inaccurate cost estimating.(19) </li></ul><ul><li>Friction between: </li></ul><ul><ul><li>Client and software contractors.(16) </li></ul></ul><ul><ul><li>Software management and senior executives.(17) </li></ul></ul>
  7. 7. Most Common Software Risks (2) (Caper Jones) <ul><li>Inadequate compensation plans.(24) </li></ul><ul><li>Inadequate configuration control and project repositories.(25) </li></ul><ul><li>Inadequate Curricula (S.E., S.M.)(26, 27). </li></ul><ul><li>Inadequate package acquisition methods.(29) </li></ul><ul><li>Inadequate software policies and standars.(31) </li></ul><ul><li>Inadequate tolls and methods (project management, Quality assurance, software engineering, technical documentation…)(34-37) </li></ul>
  8. 8. Most Common Software Risks (3) (Caper Jones) <ul><li>Lack of reusable code, data, test, human interfaces.(41-47) </li></ul><ul><li>Lack of specialization (48). </li></ul><ul><li>Low user satisfaction(53). </li></ul><ul><li>Low productivity.(50) </li></ul><ul><li>High maintenance costs.(18) </li></ul><ul><li>Partial live cycle definitions.(57) </li></ul><ul><li>poor technology investments. </li></ul><ul><li>Silver bullet syndrome.(62) </li></ul>
  9. 9. Specific risk causes. <ul><li>“ When a project is successful, it is not because there are no problems, but because the problems were overcome .” </li></ul><ul><li>We can act: </li></ul><ul><ul><li>Reactive: we wait problems and then we act on them. </li></ul></ul><ul><ul><li>Proactive: We identify potential problems and act in anticipation </li></ul></ul>
  10. 10. Risk management elements <ul><li>Different techniques to work whit risk. </li></ul><ul><ul><li>The spiral life cycle. </li></ul></ul><ul><ul><li>Check lists </li></ul></ul><ul><ul><li>Risk management. </li></ul></ul><ul><li>This methods can work all together. </li></ul>
  11. 11. Risk management procedures <ul><li>Identify risk factors </li></ul><ul><li>Asses risk probabilities and effects on the project </li></ul><ul><li>Develop strategies to mitigate identify risks </li></ul><ul><li>Monitoring Risk factors </li></ul><ul><li>Invoke a contingence plan. </li></ul><ul><li>Manage the crisis. </li></ul><ul><li>Recovery from a crisis. </li></ul><ul><ul><ul><ul><ul><li>Fairley, R. IEEE Software Mayo 1994 </li></ul></ul></ul></ul></ul>
  12. 12. Identify risk factors <ul><li>You must visualize the project development and identify “wrong” things. </li></ul><ul><li>If you have a checklist with problems in other projects you work then revise that list. </li></ul><ul><ul><li>“ Who don’t know their past is commended to repeat” </li></ul></ul>
  13. 13. <ul><li>You must difference cause (risk factors), problems and symptoms. </li></ul><ul><li>Whether you identify a situation as a risk or an opportunity depends on your point of view. </li></ul><ul><li>Is the glass half full or half empty? </li></ul><ul><ul><li>Situations with high potential for failure often have the potential for high pay back. </li></ul></ul>
  14. 14. Asses risk probabilities and effects on the project <ul><li>Evaluate the probability of this problem. </li></ul><ul><li>Evaluate the effect the problem would have on the project desired outcome. </li></ul><ul><li>Classify risks with the Risk exposure, calculated as: </li></ul><ul><ul><li>Probability * Effect </li></ul></ul><ul><li>As a consecuence we will identify more important risks. </li></ul>
  15. 15. Evaluación de la probabilidad de que se de el problema. <ul><li>Not all the problems have the same probability. </li></ul><ul><li>Some times evaluating the probability is something difficult, use </li></ul><ul><ul><li>Similar cases . </li></ul></ul><ul><ul><li>Optimist, pessimist and more probable. </li></ul></ul><ul><ul><li>Remember the Murphy law: </li></ul></ul><ul><ul><ul><li>“ if something can go wrong, it will do” </li></ul></ul></ul><ul><li>We can use simulation tools. </li></ul>
  16. 16. Develop strategies to mitigate identify risks <ul><li>Two types of strategies: </li></ul><ul><ul><li>Action planning. </li></ul></ul><ul><ul><ul><li>Addresses risks that can be mitigated by immediate response </li></ul></ul></ul><ul><ul><li>Contingency planning. </li></ul></ul><ul><ul><ul><li>We accept the risk and we plan and control the risk. </li></ul></ul></ul>
  17. 17. Action planning <ul><li>We minimize or vanish the risk. </li></ul><ul><li>We take action before the problem will materialize. </li></ul><ul><ul><li>Example: </li></ul></ul><ul><ul><ul><li>Problem: We can have problem using new tolls. </li></ul></ul></ul><ul><ul><ul><li>Action: We hire a experienced worker whit this tools </li></ul></ul></ul>
  18. 18. Contingency planning <ul><li>We accept the risk and we prepare a plan and we will use this if the risk is materialized. </li></ul><ul><li>The actions to take are: </li></ul><ul><ul><li>Identify variables to be control in order to detect that the problem is here. </li></ul></ul><ul><ul><li>Create an action plan to be used during the crisis, as a consequence of this problem. </li></ul></ul><ul><ul><li>Planning the crisis recovery. </li></ul></ul>
  19. 19. Monitoring Risk factors <ul><li>We observe identify symptoms, grouped. </li></ul><ul><li>We must quantify in a precise manner with objective, timely and accurate metrics. </li></ul><ul><li>We must have a clear control limits </li></ul><ul><li>We need a tradability between risk factors and risks. </li></ul>
  20. 20. Invoke a contingence plan <ul><li>When a quantitative risk indicator crosses a predetermined threshold. </li></ul><ul><li>Usually you can have different levels, </li></ul><ul><ul><li>At first levels the operative level take action, </li></ul></ul><ul><ul><li>If can’t correct the situation then the contingency plan will start. </li></ul></ul>
  21. 21. Manage the crisis <ul><li>Despite a team’s best effort, the contingence plan may fail, in which case project enters crisis mode </li></ul>
  22. 22. Recovery from a crisis <ul><li>After a crisis certain actions are required: </li></ul><ul><ul><li>Reward personnel who have worked in burnout mode, </li></ul></ul><ul><ul><li>Reevaluating cost and schedule in light of the drain on resources from managing the crisis. </li></ul></ul>
  23. 23. Bibliografía <ul><li>Fairley, R. “Risk Management for Software Development” en Software Engineering editado por Dorffman, M y Thayer, R.H., IEEE Computer Society, 1997 </li></ul><ul><li>Fairley, R. “Risk Management for Software Projects”, IEEE Software, Mayo 1994 </li></ul><ul><li>Jones, C. Assessment and Control of Software Risks. Yourdon Press, Prentice Hall, 1994. </li></ul>