Project

Managemen
t
ORGANISING, PLANNING AND SCHEDULING
SOFTWARE PROJECTS
Objectives
To discuss the notion of risks and the risk management process
Topics covered
Risk management
Risk management
Risk management is concerned with identifying risks and drawing up
plans to minimise their effect on a project.
A risk is a probability that some adverse circumstance will occur.
◦ Project risks affect schedule or resources
◦ Product risks affect the quality or performance of the software being
developed
◦ Business risks affect the organisation developing or procuring the software
Software risks
Risk Risk type Description
Staff turnover Project Experienced staff will leave the
project before it is finished.
Management change Project There will be a change of
organisational management with
different priorities.
Hardware unavailability Project Hardware which is essential for the
project will not be delivered on
schedule.
Requirements change Project and There will be a larger number of
product changes to the requirements than
anticipated.
Specification delays Project and Specifications of essential interfaces
product are not available on schedule
Size underestimate Project and The size of the system has been
product underestimated.
CASE tool under- Product CASE tools which support the
performance project do not perform as anticipated
Tec hnology change Business The underlying technology on which
the system is built is superseded by
new technology.
Product competition Business A competitive product is marketed
before the system is completed.
The risk management
process
Risk identification
◦ Identify project, product and business risks

Risk analysis
◦ Assess the likelihood and consequences of these risks

Risk planning
◦ Draw up plans to avoid or minimise the effects of the risk

Risk monitoring
◦ Monitor the risks throughout the project
 The risk management
process

Risk Risk analysis Risk planning Risk

identification monitoring

List of potential Risk avoidance Risk

Prioritised risk and contingency
risks list assessment
plans
Risk identification
 Technology risks
 People risks
 Organisational risks
 Requirements risks
 Estimation risks
Risks and risk types
Risk type Possible risks
Technology The database used in the system cannot process as many
transactions per second as expected.
Software components which should be reused contain defects
which limit their functionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organisational The organisation is restructured so that different management
are responsible for the project.
Organisational financial problems force reductions in the project
budget.
Tools The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
Requirements Changes to requirements which require major design rework are
proposed.
Customers fail to understand the impact of requirements
changes.
Estimation The time required to develop the software is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.
Risk analysis
 Assess probability and seriousness of each risk
 Probability may be very low, low, moderate, high or very high
 Risk effects might be catastrophic, serious, tolerable or insignificant
Risk analysis
Risk Probability Effects
Organisational financial problems force reductions Low Catastrophic
in the project budget.
It is impossible to recruit staff with the skills High Catastrophic
required for the project.
Key staff are ill at critical times in the project. Moderate Serious
Software components which should be reused Moderate Serious
contain defects which limit their functionality.
Changes to requirements which require major Moderate Serious
design rework are proposed.
The organisation is restructured so that different High Serious
management are responsible for the project.
The database used in the system cannot process as Moderate Serious
many transactions per second as expected.
The time required to develop the software is High Serious
underestimated.
CASE tools cannot be integrated. High Tolerable
Customers fail to understand the impact of Moderate Tolerable
requirements changes.
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underestimated. Moderate Tolerable
The size of the software is underestimated. High Tolerable
The code generated by CASE tools is inefficient. Moderate Insignificant
Risk planning
Consider each risk and develop a strategy to manage that risk
Avoidance strategies
◦ The probability that the risk will arise is reduced

Minimisation strategies
◦ The impact of the risk on the project or product will be reduced

Contingency plans
◦ If the risk arises, contingency plans are plans to deal with that risk
Risk management
strategies
Risk Strategy
Organisational Prepare a briefing document for senior management showing
financial problems how the project is making a very important contribution to the
goals of the business.
Recruitment Alert customer of potential difficulties and the possibility of
problems delays, investigate buying-in components.
Staff illness Reorganise team so that there is more overlap of work and
people therefore understand each other’s jobs.
Defective Replace potentially defective components with bought-in
components components of known reliability.
Requirements Derive traceability information to assess requirements change
changes impact, maximise information hiding in the design.
Organisational Prepare a briefing document for senior management showing
restructuring how the project is making a very important contribution to the
goals of the business.
Database Investigate the possibility of buying a higher-performance
performance database.
Underestimated Investigate buying in components, investigate use of a program
development time generator.
Risk monitoring
Assess each identified risks regularly to decide whether or not it is
becoming less or more probable
Also assess whether the effects of the risk have changed
Each key risk should be discussed at management progress meetings
 Risk factors
Risk type Potential indicators
Technology Late delivery of hardware or support software, many
reported technology problems
People Poor staff morale, poor relationships amongst team
member, job availability
Organisational organisational gossip, lack of action by senior
management
Tools reluctance by team members to use tools, complaints
about CASE tools, demands for higher-powered
workstations
Requirements many requirements change requests, customer
complaints
Estimation failure to meet agreed schedule, failure to clear
reported defects
Key points
Risks may be project risks, product risks or business risks
Risk management is concerned with identifying risks which may affect the
project and planning to ensure that these risks do not develop into major
threats