Risk management in software projects
This presentation is the property of its rightful owner.
Sponsored Links
1 / 23

Risk management in Software Projects PowerPoint PPT Presentation


  • 101 Views
  • Uploaded on
  • Presentation posted in: General

Risk management in Software Projects. José Onofre Montesa Andrés Universidad Politécnica de Valencia Escuela Superior de Informática Aplicada 2003-2004. Índice . Failure and root causes. Risk Definition Formas en las que se afrontan las causas de las desviaciones

Download Presentation

Risk management in Software Projects

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Risk management in software projects

Risk management in Software Projects

José Onofre Montesa Andrés

Universidad Politécnica de Valencia

Escuela Superior de Informática Aplicada

2003-2004


Ndice

Índice

  • Failure and root causes.

  • Risk Definition

  • Formas en las que se afrontan las causas de las desviaciones

  • Elementos de la Gestión de Riesgos

    • Identificar los factores de Riesgo

    • Evaluar la probabilidad y el efecto

    • Desarrollo de estrategias para mitigar los riesgos

  • Monitorizar los factores de riesgo

GpiI-3C Risk management in Software Projects


Failure and root causes

Failure and root causes.

  • Software projects fail if:

    • Software never runs.

    • Don’t accomplish same expected functions.

    • Software isn't delivered on time.

    • Higher cost than expected.

  • Reasons:

    • High level of complexity (communications, interrelation with other systems, etc..)

    • Uncertainty. It wasn’t clear the objective.

GpiI-3C Risk management in Software Projects


Risk definition fairley

Risk Definition (Fairley)

  • Risk is a potential problem.

  • Problem is a risk that has materialized.

  • By a problem, we mean an undesirable situation that will require time and resources to correct.

    • (may be uncorrectable).

  • A risk is characterized by:

    • The probability that occur (0<P<1)

    • A loss associated

GpiI-3C Risk management in Software Projects


Risk factors fall into two categories

Risk factors fall into two categories

  • Generic risks, common to all software projects, then we tray to improve the organization to overcome this risks or we have a check list.

  • Project specific risks.

  • This are complementary points of view we must act on both.

  • GpiI-3C Risk management in Software Projects


    Most common software risks 1 caper jones

    Most Common Software Risks (1) (Caper Jones)

    • Ambiguous improvement targets.(4)

    • Creeping users requirements.(9)

    • Crowded office conditions.(10)

    • Excessive schedule pressure.(13)

    • Excessive time to market.(14)

    • Inaccurate cost estimating.(19)

    • Friction between:

      • Client and software contractors.(16)

      • Software management and senior executives.(17)

    GpiI-3C Risk management in Software Projects


    Most common software risks 2 caper jones

    Most Common Software Risks (2) (Caper Jones)

    • Inadequate compensation plans.(24)

    • Inadequate configuration control and project repositories.(25)

    • Inadequate Curricula (S.E., S.M.)(26, 27).

    • Inadequate package acquisition methods.(29)

    • Inadequate software policies and standars.(31)

    • Inadequate tolls and methods (project management, Quality assurance, software engineering, technical documentation…)(34-37)

    GpiI-3C Risk management in Software Projects


    Most common software risks 3 caper jones

    Most Common Software Risks (3) (Caper Jones)

    • Lack of reusable code, data, test, human interfaces.(41-47)

    • Lack of specialization (48).

    • Low user satisfaction(53).

    • Low productivity.(50)

    • High maintenance costs.(18)

    • Partial live cycle definitions.(57)

    • poor technology investments.

    • Silver bullet syndrome.(62)

    GpiI-3C Risk management in Software Projects


    Specific risk causes

    Specific risk causes.

    • “When a project is successful, it is not because there are no problems, but because the problems were overcome .”

    • We can act:

      • Reactive: we wait problems and then we act on them.

      • Proactive: We identify potential problems and act in anticipation

    GpiI-3C Risk management in Software Projects


    Risk management elements

    Risk management elements

    • Different techniques to work whit risk.

      • The spiral life cycle.

      • Check lists

      • Risk management.

    • This methods can work all together.

    GpiI-3C Risk management in Software Projects


    Risk management procedures

    Risk management procedures

    • Identify risk factors

    • Asses risk probabilities and effects on the project

    • Develop strategies to mitigate identify risks

    • Monitoring Risk factors

    • Invoke a contingence plan.

    • Manage the crisis.

    • Recovery from a crisis.

      • Fairley, R. IEEE Software Mayo 1994

    GpiI-3C Risk management in Software Projects


    Identify risk factors

    Identify risk factors

    • You must visualize the project development and identify “wrong” things.

    • If you have a checklist with problems in other projects you work then revise that list.

      • “Who don’t know their past is commended to repeat”

    GpiI-3C Risk management in Software Projects


    Risk management in software projects

    • You must difference cause (risk factors), problems and symptoms.

    • Whether you identify a situation as a risk or an opportunity depends on your point of view.

    • Is the glass half full or half empty?

      • Situations with high potential for failure often have the potential for high pay back.

    GpiI-3C Risk management in Software Projects


    Asses risk probabilities and effects on the project

    Asses risk probabilities and effects on the project

    • Evaluate the probability of this problem.

    • Evaluate the effect the problem would have on the project desired outcome.

    • Classify risks with the Risk exposure, calculated as:

      • Probability * Effect

    • As a consecuence we will identify more important risks.

    GpiI-3C Risk management in Software Projects


    Evaluaci n de la probabilidad de que se de el problema

    Evaluación de la probabilidad de que se de el problema.

    • Not all the problems have the same probability.

    • Some times evaluating the probability is something difficult, use

      • Similar cases .

      • Optimist, pessimist and more probable.

      • Remember the Murphy law:

        • “if something can go wrong, it will do”

    • We can use simulation tools.

    GpiI-3C Risk management in Software Projects


    Develop strategies to mitigate identify risks

    Develop strategies to mitigate identify risks

    • Two types of strategies:

      • Action planning.

        • Addresses risks that can be mitigated by immediate response

      • Contingency planning.

        • We accept the risk and we plan and control the risk.

    GpiI-3C Risk management in Software Projects


    Action planning

    Action planning

    • We minimize or vanish the risk.

    • We take action before the problem will materialize.

      • Example:

        • Problem: We can have problem using new tolls.

        • Action: We hire a experienced worker whit this tools

    GpiI-3C Risk management in Software Projects


    Contingency planning

    Contingency planning

    • We accept the risk and we prepare a plan and we will use this if the risk is materialized.

    • The actions to take are:

      • Identify variables to be control in order to detect that the problem is here.

      • Create an action plan to be used during the crisis, as a consequence of this problem.

      • Planning the crisis recovery.

    GpiI-3C Risk management in Software Projects


    Monitoring risk factors

    Monitoring Risk factors

    • We observe identify symptoms, grouped.

    • We must quantify in a precise manner with objective, timely and accurate metrics.

    • We must have a clear control limits

    • We need a tradability between risk factors and risks.

    GpiI-3C Risk management in Software Projects


    Invoke a contingence plan

    Invoke a contingence plan

    • When a quantitative risk indicator crosses a predetermined threshold.

    • Usually you can have different levels,

      • At first levels the operative level take action,

      • If can’t correct the situation then the contingency plan will start.

    GpiI-3C Risk management in Software Projects


    Manage the crisis

    Manage the crisis

    • Despite a team’s best effort, the contingence plan may fail, in which case project enters crisis mode

    GpiI-3C Risk management in Software Projects


    Recovery from a crisis

    Recovery from a crisis

    • After a crisis certain actions are required:

      • Reward personnel who have worked in burnout mode,

      • Reevaluating cost and schedule in light of the drain on resources from managing the crisis.

    GpiI-3C Risk management in Software Projects


    Bibliograf a

    Bibliografía

    • Fairley, R. “Risk Management for Software Development” en Software Engineering editado por Dorffman, M y Thayer, R.H., IEEE Computer Society, 1997

    • Fairley, R. “Risk Management for Software Projects”, IEEE Software, Mayo 1994

    • Jones, C. Assessment and Control of Software Risks. Yourdon Press, Prentice Hall, 1994.

    GpiI-3C Risk management in Software Projects


  • Login