Lecture 8

SPM
Risk Management
Introduction
• Some risks are important than others, depending on the nature of risk
like effecting the criticality of an activity (delaying project and running
of over budget)
• i.e. activities on critical path (which we discussed in previous lecture)
are of high concern if they contains risk
• The aim of risk management is to minimize the risks by
 Distributing it in the project
 And ideally, by removing risk from the activities laying on critical path
• Risk evaluation and resources allocation are closely connected
Risk management stages in step wise
0.Select
project
1. Identify 2. Identify project
project objectives infrastructure
3. Analyze
project
characteristics
Review
4. Identify products
and activities

5. Estimate effort
Lower for activity For each
level activity
detail 6. Identify activity
risks
10. Lower level
7. Allocate
planning
resources

8. Review/ publicize
9. Execute plan plan
Overview
• Project risks
• Nature of risks
• Risk identification
• Risk estimation
• Risk evaluation
• Risk management
• Risk reduction strategies
Boehm’s Risk Engineering
Ris k
Engin eerin g

Ris k Ris k
Analysis Management

Ris k Ris k Ris k Ris k Ris k Ris k Ris k Ris k

Identific atio n Estim atio n Evalu atio n Pla nnin g Control Monitorin g Directin g Staffin g
Project Risks
• Factors that cause a project to be delayed or over-budget

• It is important that we want to build and deliver the product on time

and within budget.

• Any factors that cause delay or over-budget are potential threats to

the project.
Nature of Project Risks
• Project risk are based on three factors

Planning assumptions

Estimation errors

Eventualities
Planning assumptions
• Uncertainties in early stage of the project
• We all make assumptions due to uncertainties in the early stage of
the project. What happen if the assumptions turn out to be invalid?
• During the project evaluation (feasibility study), we have some
estimations (e.g. size or time), which are based on some assumptions.
• Based on these estimations and assumptions, we decide whether to
continue the project or not.
• Thus, anything that goes wrong with the estimations and assumptions
are potential threats to the project.
Planning assumptions
• Common assumption:
 “Everything will go smoothly”
 Environment is reliable and fixed
 Design will be perfect first time
 Coding will be ‘nearly perfect’

• Guidelines
• List all the assumptions
• Identify the effects of these assumptions on the project if they are no longer
valid
Estimation errors
• Difficult to have accurate size or time estimations
 Lack of experience of similar tasks
 Lack of historical data
 Nature of the task
• These three factors (experience, history, nature) are interrelated.
• For example, if we are to document the user manuals and we have done
this for a similar system, the estimation will be accurate to some extent.
• However, if we are to test and debug the system, it is then difficult to
have a good estimate even if we have tested and debugged a similar
system before.
Estimation errors
• Estimation can be improved by analyzing historic data for similar tasks
and similar projects
 Keep historic data of your estimation and the actual performance
 Compare your estimation and the actual value
 Classify the tasks that are easy or difficult to give accurate estimation
• In order to improve the estimation, you need to have lots of historic
data and need to analyze your estimation with the actual
performance.
Eventualities
• Unexpected and unimaginable events
• Common unexpected events
• Hardware cannot be delivered on time
• Requirements specification needs to be rewritten
• Staffing problem
• Other unexpected events that always occur in real life
Overview
• Project risks
• Nature of risks
• Risk identification
• Risk estimation
• Risk evaluation
• Risk management
• Risk reduction strategies
Risk Identification
• Identify the hazards that might affect the duration or resource costs of the project
Hazard  Problem  Risk
• A hazard is an event that might occur and will create a problem for the successful
completion of the project, if it does occur
• Examples of hazards are:
 a team member is ill
 late delivery of a hardware component
 system down
• Hazard: Mary’s baby may be born early
• Problem: Modules P and Q will have no coder
• Risk: Milestone 7 will be delayed, or extra budget will be needed to hire another coder
Risk Identification
• Type of risks
 Generic risk
 those risks relevant to all software projects.
 Examples are misunderstanding of the requirements and key staff being ill.
 Standard checklist can be modified based on the risk analysis of previous projects
 Specific risk
 risks are those risks relevant to an individual project only.
 Team members of the project are the frontline of identifying these potential risks.
 Need to set up an encouraging risk-identification environment so that team members are
willing to share their findings.
 “Assuming that the problems will not occur does not prevent their occurrence.”
 More difficult to find
Risk Identification
• Common Risk Factors
 Application factors
 Staff factors
 Project factors
 Hardware and software factors
 Changeover factors
 Supplier factors
 Environment factors
 Health and safety factors
• Guideline
 Use checklist that lists the potential hazards and their corresponding factors
 Maintain an updated checklist for future projects
 Typical checklists may have many hazards and factors.
Application Factors
• Nature of the application
• A data processing application or a life-critical system (e.g. X-ray emission
system)
• It is a critical factor to the success of the project.
• Expected size of the application
• The larger is the size, the higher is the chance of errors, communication
problems and management problems
Staff Factors
• Experience and skills:
• Experienced programmers are less likely to make errors.
• Appropriateness of Experience:
• Experience in structural design (using JSD) may not be related to OOD in UML.
• Experience in coding Java or C++ may not be related to coding in Python.
• Staff satisfaction:
• Dissatisfied or Unmotivated staff may cause a project to fail.
• Staff turn-over rate:
• Key personnel leaving unexpectedly would cause a project to fail.
• High turn-over rate would cause much communication overhead and may delay a
project.
Project Factors
• Project objectives:
 Ill defined
 Unclear to every team member and user
• Project methods:
 Ill specified methods
 Unstructured methods
Hardware and Software Factors
• New hardware
 Stability of the new hardware system
 Usually, new hardware systems are not so stable at their early stage
• Cross platform development
 Development platform is not the operation platform
 Normally, the development platform and the operation platform are not exactly the same.
 Adjustment is needed to cater for the operation platform. This leads to extra time and effort.
 Problems may only occur in the operation platform.
 Does the language used support cross platform development?
 Availability of languages in the development platform as well as the operation platform
 High portability languages should be used such as C, C++, and Java.
 This also relates to the skills of the staff.
Changeover Factors
• ‘All-in-one’ changeover
• The new system is put into operation
• Too risky. It minimizes operation costs if everything is OK
• Incremental or gradual changeover
• Adding new components to the system by phases
• Minimizes the risk involved.
• However, it is not always practical because it involves too many issues such as
 the order of integration of the components,
 the scheduling of the components,
 the interface between the replaced components and the replacing components, and
 training of operation personnel.

• Parallel changeover
• Both the existing system and the new system are used in parallel
• A safety net, no risk at all during the parallel phases. Too costly. Sometimes, it is impossible
Supplier and Environment Factors
• Supplier Factors
 Late delivery of hardware
 Instability of hardware
 Late completion of building sites
• Environment Factors
 Changes in environment such as hardware platforms
 Changes in government policies
 Changes in business rules
 Restructuring of organizations
Health and Safety Factors
• Health and safety of staff and environment
• Staff sickness, death, pregnancy etc.
• Any tragic accident to staff
• Law and order situation
• Pandemic situation
• Extreme weathers (Floods, rains, environment temperature)
Boehm’s Top Ten Risk Items
• Personnel shortfalls
• Unrealistic schedules and budgets
• Developing the wrong software functions
• Developing the wrong user interface
• Gold plating
• Continuing stream of requirements changes
• Shortfalls in externally performed tasks
• Shortfalls in externally furnished components
• Real-time performance shortfalls
• Development technically too difficult
Risk Estimation
• Recall that
Hazard  Problem  Risk
• Risk estimation is to assess the likelihood and impact of each hazard
• Risk exposure (risk value)
 It is the importance of the risk
Risk exposure = risk likelihood × risk impact
• Risk likelihood
 The probability that a hazard is going to occur
• Rank from Low, Medium to High
• Rank from 1 (least likely) to 10 (most likely)
• Risk impact
 The effect of the problem caused by the hazard
 Ideally, it should be estimated in monetary terms.
 However, the estimated value is normally used as a guideline on the order of importance of the items rather than the
actual dollar need to rectify the problem unless you are a real good estimator
 Rank from 1 to 10
Risk Estimation
• What is the cost of the problem? This may include the following:
 The cost of delays to scheduled dates for deliverables.
 The cost overruns caused by using additional or more expensive resources.
 The costs incurred or implicit in any compromise to the quality or functionality of the
system.
• Advantages:
 To be consistent with the measures in the cost-benefit analysis
 Easy to compare the relative importance of risk exposure of various risk
 Can be directly compared with the costs and likelihoods of success of various
contingency plans.
• Disadvantages
 Estimation is difficult, subjective, time-consuming and costly
Risk Evaluation (Ranking and
Reduction)
• Ranking the risks
 Ranking only shows the order of importance of the risks not their relative sizes.
 Ranking the risks based on their risk exposures
 In practice, also consider factors like
 Confidence of the risk assessment: need to re-assess those risks that we have low
confident in more detail
 Compound risk: combine risks that depend on each other to form a single risk
 The number of risks: limit the size of the priority list
 Cost of action: Risk with low fixing costs can be incorporated into the project while
Risk with high fixing costs should be considered whether the cost of action will
outweigh the benefits of reducing the risk.
• Determining the corresponding risk reduction strategies
Risk Reduction Leverage (RRL)
• RRL is used to determine whether it is worthwhile to carry out the risk
reduction plan.
• The higher is the RRL value, the more worthwhile is to carry out the
risk reduction plan.
RE before  RE after
RRL 
risk reduction cost
• If RRL > 1, there is a gain from enacting the plan. Go ahead
Risk Management
• Risk planning
 Making contingency plans
 Where appropriate, adding these plans into the project’s overall task structure
• Risk control
 Minimizing and reacting to problems arising from risks throughout the project
• Risk monitoring
 It is an ongoing activity throughout the whole project to monitor
 the likelihood of a hazard; and
 the impact of the problem caused.

• Risk directing and Staffing

 These concerns with the day-to-day management of risk.
 Risk aversion strategies and problem solving strategies frequently involve the use of additional
staff and this must be planned for and should be considered.
Risk Reduction Strategies
• 5 different types in a generic sense
 Hazard prevention
 Likelihood reduction
 Risk avoidance
 Risk transfer
 Contingency planning
• Distinctions among them are fuzzy
Hazard Prevention and Likelihood
Reduction
• Prevent a hazard from occurring or reduce its likelihood to an
insignificant level
 Lack of skilled staff can be prevented by employing staff with appropriate
skills
 Unclear requirements specification can be prevented by using formal
specification techniques
• Reduce the likelihood of an unavoidable risk by prior planning
 Late change to the requirements specification can be reduced by using
prototyping
Risk Avoidance, Transfer and
Contingency Plan
• Some hazards cannot be avoided but their risks may
 A project can be protected from the risk of overrunning the schedule by
increasing duration estimates.
• The impact of the risk can be transferred away from the project by
contracting out or taking out insurance
 The risk of shortfalls in external supplied components can be transferred away
by quality assurance procedures and certification, and contractual agreements
• Contingency plans are needed to reduce the impact of those risks that
cannot be avoided
 The impact of any unplanned absence of programming staff can be minimized
by using agency programmers