Risk management in Software Projects

Risk management in Software

Projects

José Onofre Montesa AndrésUniversidad Politécnica de

ValenciaEscuela Superior de Informática

Aplicada2003-2004

GpiI-3C Risk management in Software Projects 2

Í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


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.


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


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.


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)



• 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)



• 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)


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


Risk management elements• Different techniques to work whit

risk.– The spiral life cycle.– Check lists– Risk management.

• This methods can work all together.


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


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”


• 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.


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.


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.


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.


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


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.


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.


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.


Manage the crisis• Despite a team’s best effort, the

contingence plan may fail, in which case project enters crisis mode


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.


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.

Risk management in Software Projects

Documents

Transcript of Risk management in Software Projects